amflush and systemd-oomd

[Uwe Menges]

Hi,

I just updated my backup server from Fedora 35 to 37.
After the upgrade, I tried to run amflush.

The session running amflush was killed by systemd-oomd as per these
lines in the journal:

systemd[1]: session-5.scope: systemd-oomd killed some process(es) in this unit.
systemd-oomd[7544]: Considered 4 cgroups for killing, top candidates were:
systemd-oomd[7544]: Path: /user.slice/user-0.slice/session-5.scope
systemd-oomd[7544]: Memory Pressure Limit: 0.00%
systemd-oomd[7544]: Pressure: Avg10: 56.78 Avg60: 40.05 Avg300: 
14.53 Total: 53s
systemd-oomd[7544]: Current Memory Usage: 30.0G
systemd-oomd[7544]: Memory Min: 0B
systemd-oomd[7544]: Memory Low: 0B
systemd-oomd[7544]: Pgscan: 14100751

My workaround was to "systemctl edit systemd-oomd" and add "--dry-run" as 
argument
(https://www.freedesktop.org/software/systemd/man/systemd-oomd.service.html).
A "systemctl cat systemd-oomd" now has this override appended:

# /etc/systemd/system/systemd-oomd.service.d/override.conf
[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-oomd --dry-run

After "systemctl restart systemd-oomd", this makes the log look like this when 
running amflush:

systemd-oomd[13095]: oomd dry-run: Would have tried to kill 
/sys/fs/cgroup/user.slice/user-0.slice/session-3.scope with recurse=true
systemd-oomd[13095]: Considered 4 cgroups for killing, top candidates were:
systemd-oomd[13095]: Path: /user.slice/user-0.slice/session-3.scope
systemd-oomd[13095]: Memory Pressure Limit: 0.00%
systemd-oomd[13095]: Pressure: Avg10: 54.15 Avg60: 35.63 
Avg300: 15.82 Total: 1min 25s
systemd-oomd[13095]: Current Memory Usage: 29.9G
systemd-oomd[13095]: Memory Min: 0B
systemd-oomd[13095]: Memory Low: 0B
systemd-oomd[13095]: Pgscan: 40620400
systemd-oomd[13095]: Last Pgscan: 40620400

And now amflush keeps running fine again.

I'm not sure what the right solution is, I just quickly wanted to get it
running again, and my itch is scratched.

Maybe something needs to be tweaked in systemd-oomd, or the amanda
package should include something to exempt amanda from systemd-oomd, or
something else.

Yours, Uwe

Re: native LTO encryption with Amanda

[Uwe Menges]

On 2020-05-19 23:56, Chris Hoogendyk wrote:
> I've seen discussions of amcrypt and pgp (I confess I haven't followed
> them closely), but is it possible to configure amanda to handle keys for
> the native LTO drive encryption?

It isn't really "configure amanda" in the following use case, but maybe it 
helps anyways.

As oftentimes, a wrapper script is used. Amanda does daily backup to
holding disk only, and this script is run to flush it to tape if there is
enough to somewhat fill it.

-8<- cut here -8<-
#!/bin/bash
# Flush amanda holding disk to tape if there is enough to fill a tape

used=$(df --output=used /backup/amanda/ | tail -n 1)
if [ $used -gt 20 ]; then
# turn on encryption of the tape
# note that we need key index "1" or we will get "IllegalRequest"
# --ckod instructs the tape to remove the key when tape is unmounted
/usr/local/bin/stenc -f /dev/nst0 -e on --protect -k 
/etc/amanda/DailySet/tape.key -a 1 --ckod
su - backup -c "amflush DailySet -b -f && mt -f /dev/nst0 eject"
fi
-8<- cut here -8<-

Yours, Uwe

Re: holding disk too small?

[Uwe Menges]

On 2019-12-05 06:00, Gene Heskett wrote:
> Lesson #2, I just learned today that the raspbian AND debian buster 10.2
> versions have NO inetd or xinetd. Ditto for RH.

I think that's along with other stuff moving to systemd.
On Fedora 30, I have

# systemctl status amanda.socket
● amanda.socket - Amanda Activation Socket
   Loaded: loaded (/usr/lib/systemd/system/amanda.socket; enabled;
vendor preset: disabled)
   Active: active (listening) since Sat 2019-11-30 14:46:46 CET; 4 days ago
   Listen: [::]:10080 (Stream)
 Accepted: 0; Connected: 0;
Tasks: 0 (limit: 4915)
   Memory: 0B
   CGroup: /system.slice/amanda.socket

Nov 30 14:46:46 lima systemd[1]: Listening on Amanda Activation Socket.

# systemctl cat amanda.socket
# /usr/lib/systemd/system/amanda.socket
[Unit]
Description=Amanda Activation Socket

[Socket]
ListenStream=10080
Accept=true

[Install]
WantedBy=sockets.target


Yours, Uwe

Re: new reject msg from an arm64 buster install -- /usr/bin/tar executable?

[Uwe Menges]

On 9/4/19 7:43 PM, Gene Heskett wrote:
> On Wednesday 04 September 2019 12:36:43 Charles Curley wrote:
>> I don't understand it either, but then again all I know is what Nathan
>> pointed out in the release notes:
>> https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-ne
>> w.en.html#merged-usr
>>
> Which contains zero *reasons* for the change.

It contains a link for the rationale:
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

There is also a debian page:
https://wiki.debian.org/UsrMerge

Yours, Uwe

Re: new reject msg from an arm64 buster install -- /usr/bin/tar executable?

[Uwe Menges]

On 9/4/19 6:10 PM, Gene Heskett wrote:
> On other question, why can I not "reply to list".  Its a pita to have to
> copy/paste the  list address into the blank To: line.

For "reply to list" to work, it seems the message needs to contain a
"List-Post" header, which isn't present on amanda mailing list messages.

On e.g. bug-tar, it looks like

List-Post: 

Yours, Uwe

Re: seperating backups methods

[Uwe Menges]

Hi Gene,

On 8/30/19 10:16 PM, Gene Heskett wrote:
> I need some ideas on how to separate this into backups that stay with the
> installs.
>
> So how to the rest of you handle this, so in the event of needing to do a
> recovery, one is prevented from mixing up packages between distro's?
>
> Thanks for any good ideas.

My idea would be to separate the OS specific DLE into different amanda
configs, then use eg. "amdump rpi-common" and "amdump rpi-sd1", "amdump
rpi-sd2" and alike.

To make the distinction of -sdX somewhat automatic, I'd probably create
a wrapper script that ssh's into the rpi using the static hostname and
cats some file on the sd, eg.

```
#!/bin/bash
hostname=rpi-3b
config=$("ssh $hostname cat /etc/amanda/config_to_use")
amdump $config
```

With /etc/amanda/config_to_use containing "rpi-sd1", "rpi-sd2" etc. on
the different sd cards.

I imagine this should work right away if you have ssh auth configured
(not too strictly) so amanda user can get to rpi-3b via ssh already
without password or questions.


Another way could be to split OS specific DLE into different hostnames
eg. "rpi-sd1" which you all map to the same ip address as the static
hostname (eg. via /etc/hosts), but you could then use to distinct them
for amanda.

Yours, Uwe

Re: tar backups not doing incrementals

[Uwe Menges]

On 6/15/19 6:43 PM, Jim Kusznir wrote:
> Ever since, any backup is run as a level 0 (even though it reports doing
> a level 1, 2, etc).  Everything runs as 0.
>
> How do I fix this?

I fixed a similar symptom on my system with
  property "CHECK-DEVICE" "NO"
(using amgtar), which hands "--no-check-device" to GNU tar,
which makes it no longer think the toplevel dir has been renamed,
so it doesn't store all files in its incremental.

I think what happened to me is that some LVM volumes got mounted with a
different minor number, triggering that.

Given that LVM is really common nowadays, I wonder if that option should
be default.. I can't think of a use case where the current default is
preferable, at the moment.

Yours, Uwe

Re: Building amanda on Debian 9 from git

[Uwe Menges]

Hi Charles,

On 5/12/19 8:36 PM, Charles Curley wrote:
> With that, my setup script now looks like:
[...]
> if [ ! -d /home/amandabackup/.ssh ] ; then
> echo Copying .ssh for user amandabackup
> cp -rp /root/.ssh /home/amandabackup

This copies also root's private key(s) and authorized_keys and config,
which is not desired. You should probably create at least one separate
key pair for amandabackup (it's up to you if you create a separate key
for each client and maintain ~amandabackup/.ssh/authorized_keys for each
client).

> And I'm not sure I need the .ssh in there. Does amanda ever use that
> user?

I believe amanda would use ssh if you configure it with ssh auth.

Yours, Uwe

Re: smbclient usage fails with "Unable to initialize messaging context"

[Uwe Menges]

On 1/4/19 7:51 PM, Stefan G. Weichinger wrote:
> I couldn't find a way to exclude/ignore such messages from smbclient
> within amsamba. And browsing the script itself it wasn't clear to me
> non-coder how and where to add that.

I'm not able to test that, my perl is rusty, I didn't take a close look,
yadda yadda..

Try to add to amsamba after both (L433 + L521):
next if /^WARNING/g;
+   next if /^Unable to initialize messaging context/g;

Or if the message doesn't really start at first column, omit the ^.

Yours, Uwe

Re: smbclient usage fails with "Unable to initialize messaging context"

[Uwe Menges]

On 1/2/19 8:19 PM, Stefan G. Weichinger wrote:
>> at first: happy new year to all you amanda-users!

Happy new year as well!

>> Today I noticed that one server running Debian 9.6 and Samba-4.8.8 fails
>> to amcheck/amdump:
>>
>> Amanda Backup Client Hosts Check
>> 
>> HOST backup ERROR: smbclient: Unable to initialize messaging context
>> HOST backup ERROR: //192.168.16.230/ELBA5: Application 'amsamba': exited
>> with status 1
[...]
>> https://lists.samba.org/archive/samba/2019-January/220209.html
>>
>> maybe it is safe and working to ignore it, I will try to let amsamba
>> ignore that message.
> 
> I'd be thankful for any help with patching amsamba.

I don't use smb or amsamba, so I don't know what it does in depth.
But I don't yet understand from your e-mail what's happening at all.

Is this an error that prevents it from working or just a message you
want to get rid of? Exit status 1 (from amsamba, but probably also from
smbclient?) indicates more than a nuisance.

Do you get the same error from a shell when trying smbclient command
that amanda/amsamba produces? Maybe the issue needs to be analyzed and
solved underneath amanda.

Yours, Uwe

Re: Meeting Minutes : Amanda Open Source Community

[Uwe Menges]

On 10/17/18 10:37 PM, Ashwin Krishna wrote:
> The previous call was to understand the pain points of the community
> in general for governance and contributions. Based on the feedback
> from those who attended, we have come up with the action plan as
> mentioned in the previous mail and we will drive it.

[BUMP]

I didn't see a very concrete action plan with responsibilities or dates
in the previous e-mail.

I don't know anything about the situation at BETSOL, Zmanda, JLM with
regards to staffing and funding for the amanda / Zmanda development (or
in general). Or how the development process used to be, besides what can
be seen on github.

So here's my 2ct.

As the meeting minutes state and others already pointed out we should
probably use github with wiki. So someone with access rights should tick
[x] Wikis on github's Settings page and/or enable Pages. AFAICS there
are two people, martineau and NingZhangWisc according to
.

ASAP you (or we?) should find someone to enable small PR merges so eg.
Dustins fix PR#92 and others can get into a minor version bump later.

There probably needs to be a software architect that decides directions
for heavier things like Chap's PR#78. Is there one? Are there (paid?)
people working on github issues?

The suggestions from Dustin were also good and should find their way in
some kind of roadmap (which could be a simple .md on github).

Some eg. monthly information for the community what's happening behind
the scenes would be nice.

Yours, Uwe

Re: amstatus lapsed time

[Uwe Menges]

On 12/4/18 5:41 PM, Chris Nighswonger wrote:
> So when I run amstatus  I see stuff like this:
> 
> From Mon Dec  3 22:00:01 EST 2018
> 
> 
> 
> 1359952k dumping   533792k (148.30%) (1+11:29:10)
> 
> For reference:
> 
> backup@scriptor:~ date
> Tue Dec  4 11:37:07 EST 2018
> 
> I'm assuming that the last field is the time the dumper has been
> running. But that is impossible as this dump began at 2200 yesterday and
> amstatus was run at 1129 today (12:29 later). So it appears that the
> 11:29:10 part is nearly correct, but the 1+ part is clearly not.

The last column is the current time for running dumps, or the last time
it was dumping for DLEs that are already dumped (== finish time).

There is special coding in place to put N+ in front of the current time
if it was started on N day(s) before now, see
https://github.com/zmanda/amanda/blob/b2fd140efb54e1ebca464f0a9ff407460d8c350b/perl/Amanda/Status.pm#L2301

Yours, Uwe

Re: What are the correct permissions for lib binaries for amanda 3.5

[Uwe Menges]

On 10/16/17 21:32, Austin S. Hemmelgarn wrote:
> Aside from that though, it's a case where the benefit to security is
> dependent on things that just aren't true for most systems amanda is
> likely to run on, namely that an attacker is:
> 
> 1. Unable to determine what type of system you're running on. (This is a
> patently false assumption on any publicly available distro, as well as
> most paid ones like OEL, RHEL, and SLES).
> &
> 2. Unable to access the packages directly.

What do these points have to do with the suid binary not being read- and
executable by normal users on that system?

I think one "why" explanation is that a local user probably can't
exploit eventual issues in the suid binary if he can't execute it.

Yours, Uwe

Re: Labelstr issues with 3.4.3

[Uwe Menges]

On 05/02/17 03:19, Luc Lalonde wrote:
> Since upgrading to 3.4.3 I seem to having problems with Amanda recognizing my 
> tapes.
> 
> Here’s the ‘labelstr’ directive in my ‘amanda.conf’:
> labelstr "^000[0-9][0-9][0-9]*”
> This worked fine when I was running version 3.3.4-1…  But now, I’m getting 
> errors.
> 
> Here are examples of some of my labels:
> 
> 000253L5
[...]
> 000219L

This wasn't a proper match before, according to
http://wiki.zmanda.com/man/amanda.conf.5.html `labelstr` is "The tape
label constraint regular expression."
The 'L' isn't mentioned in your regex (maybe you meant it as glob, but
globs don't know '^').

> Can someone explain what changed?

Maybe this one:
https://github.com/zmanda/amanda/commit/99d85cb28071990cfe566aca25241515bbbc32bd

Yours, Uwe

Re: segfault from planner (3.4.2-1)

[Uwe Menges]

On 02/20/17 13:55, Jean-Louis Martineau wrote:
> Can you tried the attached patch instead of yours?

Sure, and thanks, this is a better patch.

Just running an extraordinary backup now, looks good so far (when
hitting the issue, it was very early during backup, so I'm already
beyond the issue).

Yours, Uwe

Re: Fedora bug report: 3.4.2 amdump does nothing; 3.4.1 is OK

[Uwe Menges]

On 02/20/17 18:30, Jason L Tibbitts III wrote:
> In https://bugzilla.redhat.com/show_bug.cgi?id=1423471 a Fedora user
> reports that amdump simply does nothing in 3.4.2 besides return exit
> code 9 (error || RESULT_MISSING).  However, 3.4.1 works fine.  We didn't
> change anything in the packaging between 3.4.1 and 3.4.2 besides add the
> patch to fix the sse-related compilation issues on non x86
> architectures.
> 
> I'm kind of at a loss.  Anyone have any hints or suggestions that I can
> pass on?  I can provide the user with packages containing reverts and
> such but I wouldn't know where to start.

Try to use the patch from JLM, this looks like exactly my problem.
I updated the BZ with that info.

Yours, Uwe

segfault from planner (3.4.2-1)

[Uwe Menges]

Hi,

Today I got a segfault from planner when I tried to run the weekly
backup on my Fedora 24 workstation:

Feb 18 12:16:26 lima audit[4905]: ANOM_ABEND auid=1000 uid=0 gid=6 ses=11 
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=4905 
comm="planner" exe="/usr/lib64/amanda/planner" sig=11
Feb 18 12:16:26 lima kernel: planner[4905]: segfault at 0 ip 7f20c57cd47a 
sp 7fff62d27ae8 error 4 in libc-2.23.so[7f20c5731000+1b9000]

After some debugging efforts involving wrapping planner in valgrind, I
got that:

==27328== 1 errors in context 1 of 20:
==27328== Invalid read of size 1
==27328==at 0x8432460: __strcmp_sse2_unaligned (in /usr/lib64/libc-2.23.so)
==27328==by 0x65AD0B8: g_str_equal (in /usr/lib64/libglib-2.0.so.0.4800.2)
==27328==by 0x4E54D88: nb_tape_in_storage (tapefile.c:1201)
==27328==by 0x10EBB0: when_overwrite (planner.c:1315)
==27328==by 0x1103AE: setup_estimate (planner.c:1024)
==27328==by 0x10DF79: main (planner.c:633)
==27328==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

The attached patch seems to fix the segfault for me.

Yours, Uwe

diff --git a/server-src/tapefile.c b/server-src/tapefile.c
index bb06173..32066b7 100644
--- a/server-src/tapefile.c
+++ b/server-src/tapefile.c
@@ -1198,6 +1198,9 @@ nb_tape_in_storage(
 tape_t *tp;
 int nb_tapes = 0;
 
+if (storage_name == NULL)
+	return 0;
+
 for (tp = tape_list; tp != NULL; tp = tp->next) {
 	if (tp->storage &&
 	g_str_equal(storage_name, tp->storage)) {

Re: big estimate / faulty dump

[Uwe Menges]

On 01/09/17 22:19, j...@jgcomp.com wrote:
> Hmmm, rootk is "system_u", jon and all the other home dirs are "unconfined_u".
> The lost+found directory is also "system_u".  If this is the problem, 
> lost+found
> should also be getting backed up and should appear in the gnutar lists.
> 
>   $ strings cyber.jgcomp.comHome_0 | grep '^\./' | grep lost
>   ./lost+found
>   ./lost+found
> 
> Sure enough, its in there.  So it a 'selinux' problem, my tar is unable to
> backup "unconfined_u" files.
> 
> So amanda and selinux configuration, something to investigate unless someone
> can point it out to me.

I filed https://bugzilla.redhat.com/show_bug.cgi?id=1280526 but I don't
know if this is really the same cause.

I currently set setenforce permissive in my backup script and setenforce
enforcing afterwards (if the script turned it off).

Yours, Uwe

Re: amanda-3.4 amtapetype: Error setting FSF_AFTER_FILEMARK

[Uwe Menges]

On 11/14/16 16:06, Jean-Francois Malouin wrote:
> amtapetype: Error setting FSF_AFTER_FILEMARK: Success at 
> /opt/amanda/sbin/amtapetype line 372.
> 
> Any ideas?

The IRC bot recently pointed at https://git.io/vXPb4

Yours, Uwe

Re: tapes and external disks: how to combine all this

[Uwe Menges]

On 11/09/16 15:57, Stefan G. Weichinger wrote:
> Is there any "mind for involving the community" in your opinion?

I have no idea, and was hoping to get some insights from people closer
related to the amanda/zmanda people. I thought maybe you know more
because of the @amanda.org address.

There recently was a question in the IRC channel:
> [...]is amanda dying?  The chat room is nearly empty.  The mailing
> lisst is a ghost list, the forum isn't sending e-mails, and the
> official builds don't run on "supported" platforms..

This is what I replied:
> might be.. the platforms are partly very outdated, too (eg. Fedora:
> current=24, latest amanda=21; Ubuntu: current=16.04, latest
> amanda=14.10)

> also, I couldn't register a wiki account, and didn't get any reply to
> that, neither here in the chan nor on the amanda-users mailing list

> development seems to be only done by JLM, and zmanda.com blog entries
> end 2013

The IRC channel's topic did still show 3.3.9 as current version 13 days
after 3.4 was released on the web page (was changed then).

So this all together indicates that there's probably not enough
resources at amanda/zmanda for keeping up? I'd be grateful for a more
"official" statement on the situation (best from people actively working
on amanda/zmanda).

Yours, Uwe

Re: tapes and external disks: how to combine all this

[Uwe Menges]

On 11/08/16 20:35, Stefan G. Weichinger wrote:
> started a small markdown file with a quick howto
> anyone interested to check and contribute?

The usual way would be to upload the markdown to a wiki, and send a link
to mailing lists or interested people.

After my last experience with the amanda wiki (not reacting on
registration attempts), I'm not sure what path the remaining amanda
staff has in mind for collaborating, or involving community. Maybe you
can shed some light on that, as you have an @amanda.org e-mail address?

Yours, Uwe

Re: amcheck failing when checking multiple clients

[Uwe Menges]

On 07/29/16 16:59, Chris Nighswonger wrote:
> Yes, but they are compiled with user 'amandabackup' whereas packages in
> the distro repo are compiled with 'backup.' The site here is large
> enough that the pain of switching the backup username would be quite large.

To get around this issue, you could duplicate the existing user with the
other name:

# grep back /etc/passwd
amandabackup:x:33:6:Amanda user:/var/lib/amanda:/bin/bash
backup:x:33:6:Amanda user:/var/lib/amanda:/bin/bash

Yours, Uwe

Re: tapes and external disks: how to combine all this

[Uwe Menges]

On 07/15/16 19:43, Stefan G. Weichinger wrote:
> Thanks for providing your script and setup.
> You should write a small howto around this and add it to the amanda wiki.

I tried to get a user account for the amanda wiki on 2016-07-19.

It requires to submit a biography, which I think is not an appropriate
requirement. It also tells "Your biography must be at least be 50 words
long.". So I wrote 50+ words which don't violate my personal privacy
policy.

Up to now, I got no reply.

AFAICS, I cannot add or edit amanda wiki pages without an account.

Yours, Uwe

Re: tapes and external disks: how to combine all this

[Uwe Menges]

On 07/15/16 04:40, Jon LaBadie wrote:
> Each was mounted wherever, but in the same place each time.
> What amanda used was a single "changer" dir of "slots" that
> were symbolic links to the vtape in that slot on its
> corresponding disk.

This is also how my setup looks like.
I have a SATA disk bay in my PC where I can put a bare disk in (without
needing trays).
I run amanda manually every week with a wrapper script, which handles a
couple of things, like disk encryption (script attached).

Yours, Uwe

# l /backup/amanda/
total 20
drwxrwx---.  3 amandabackup disk 4096 2016-07-09 21:57 ./
drwxr-xr-x. 29 root root 4096 2016-06-21 00:45 ../
lrwxrwxrwx.  1 amandabackup disk6 2016-07-09 19:17 data -> slot16
-rwxr-xr-x.  1 root root 4631 2016-03-12 16:28 do_backup.sh*
drwxr-xr-x.  2 root root 4096 2009-05-25 22:08 hold/
lrwxrwxrwx.  1 root root   16 2015-10-08 01:04 slot1 -> ../uwe-101/slot1
lrwxrwxrwx.  1 root root   17 2015-10-10 21:20 slot10 -> 
../uwe-a02/slot10
lrwxrwxrwx.  1 root root   17 2015-10-30 11:02 slot11 -> 
../uwe-a03/slot11
lrwxrwxrwx.  1 root root   17 2015-10-30 11:02 slot12 -> 
../uwe-a04/slot12
lrwxrwxrwx.  1 root root   17 2016-06-19 19:08 slot13 -> 
../uwe-a05/slot13
lrwxrwxrwx.  1 root root   17 2016-06-19 19:09 slot14 -> 
../uwe-a06/slot14
lrwxrwxrwx.  1 root root   17 2016-06-20 21:32 slot15 -> 
../uwe-a07/slot15
lrwxrwxrwx.  1 root root   17 2016-06-20 21:49 slot16 -> 
../uwe-a08/slot16

# cat /etc/amanda/uwe/amanda.conf
org ""  # your organization name for reports
mailto "admin"  # space separated list of operators at your site
dumpuser "backup"   # the user to run dumps under
usetimestamps yes   # enable more than one run per day
inparallel 4# maximum dumpers that will run in parallel
displayunit "m" # Possible values: "k|m|g|t"
netusage 1
bumpsize1 GB# minimum savings (threshold) to bump level 1 -> 2
bumpdays1   # minimum days at each level
bumpmult2   # threshold = bumpsize * (level-1)**bumpmult
dumpcycle 8 weeks   # the number of days in the normal dump cycle
tapetype vtape-1t
tpchanger "chg-disk:/backup/amanda"
tapecycle 23 # the number of tapes that are available to Amanda
runtapes 1 # how many tapes can be used for a single exec of amdump
runspercycle 8 # how many days you plan to execute amdump during one dumpcycle
labelstr "^uwe-[0-9a-f][0-9][0-9]$" # label constraint regex: all tapes 
must match
autoflush on# also flush old dumps to the tape if there are any
reserve 20 # percent of holding disk to reserve for incremental dumps if no 
tape is inserted
infofile "/var/lib/amanda/uwe/curinfo"  # database filename
logdir  "/var/log/amanda/uwe/log"
indexdir "/var/lib/amanda/uwe/index"
define tapetype vtape-1t {
comment "Virtual tapes on disks"
length 97600 kbyte # my disk is 976243896 kbyte, leave some slack for 
amanda files
}
define application-tool app_amgtar {
plugin "amgtar"
comment "amgtar with blocksize"
property "XATTRS" "YES"
property "TAR-BLOCKSIZE" "16384"
property "GNUTAR-PATH" "/usr/local/bin/tar_nocache"
}
define dumptype normal {
comment "dump with app_amgtar"
program "APPLICATION"
application "app_amgtar"
index on
auth "bsdtcp"
compress server custom
server_custom_compress "/bin/pigz"
estimate client
exclude "/etc/amanda/uwe/exclude.gtar"
priority medium
}
define dumptype uncompressed {
comment "dump with app_amgtar"
program "APPLICATION"
application "app_amgtar"
index on
auth "bsdtcp"
compress none
estimate client
exclude "/etc/amanda/uwe/exclude.gtar"
priority medium
}



do_backup.sh
Description: application/shellscript

Re: perl code snippet to process Amanda's disklist

[Uwe Menges]

On 03/09/16 23:07, Chris Hoogendyk wrote:
> Does anyone have a perl code snippet to process Amanda's disklist?
[...]
> What I would like to do is have a script on cron that would check the
> size of each DLE and send me an email alert if any one of them goes
> above some threshold. Then I can fix it before Amanda runs.

There is https://github.com/stefangweichinger/am_dyn_dles - maybe you
can (re)use or hack this.

Yours, Uwe

Re: amanda 3.3.8, SELinux, Fedora

[Uwe Menges]

On 01/26/16 12:27, Stefan G. Weichinger wrote:
> fedora tells me to use star:
> 
> https://fedoraproject.org/wiki/SELinux_FAQ#How_can_I_back_up_files_from_an_SELinux_file_system.3F

I think this is outdated, GNU tar seems to be able to preserve SELinux
contexts with GNU tar as well in the meanwhile (--selinux option, see
info pages, it's not mentioned in the man page).

> Aside from the details here, is there a recommended howto for this?

I think running in permissive and fixing the issues that appear in
audit.log is the way to go (by either labeling the FS correctly, or by
changing the policy). I'm a bit puzzled because you get different
SELinux messages than me. I opened a BZ for fowner capability of tar:
https://bugzilla.redhat.com/show_bug.cgi?id=1280526 (that was on F22, I
updated to F23 in the meanwhile).

My current workaround is to setenforce permissive at the beginning of my
backup script and reset it to enforcing at the end.

FWIW, there is also a bug with the F23-shipped amanda (or with perl,
someone with deeper perl knowledge than me needs to judge that):
https://bugzilla.redhat.com/show_bug.cgi?id=1262571

Yours, Uwe

Re: Need another stat in the emailed report

[Uwe Menges]

On 12/28/15 12:43, Gene Heskett wrote:
> In an effort to learn more about how these 4 settings work, it would be 
> advantageous to have an additional number in each DLE's line of the 
> report that tallies how long it has been since the last full level 0.

I don't know for the report, but I use this command to check my level 0:
$ amoverview uwe -diskwidth 40 -skipmissed -num0 -togo0 | grep --color 0

Yours, Uwe

Re: [Amanda-users] Getting started

[Uwe Menges]

On 05/06/2010 04:06 PM, jasonswett wrote:
 I've looked into Amanda a little bit but just came out confused. I don't have 
 any storage media but I'm willing to buy some.
 
 Can anyone help point me in the right direction?

I'm using an E-SATA docking station with 1TB disks (LUKS dm-crypted) as
a vtape, a cheap and fast solution.

Yours, Uwe

Re: request: script for generating DLEs

[Uwe Menges]

On 04/20/2010 10:49 PM, Stefan G. Weichinger wrote:
 I'd like to have a script that generates include-lists for amanda-DLEs
 ... the script should accept a parameter defining the overall size of
 the DLE.
 
 background:

 But I prefer to ask you, the amanda-users, in advance ... as there is
 quite a good chance that one of you already has such a script working
 already.

No script, sorry...

This task probably requires some clever find/scan part with size
calculation that assembles regex for the varying directories/files:

http://wiki.zmanda.com/index.php/How_To:Split_DLEs_With_Exclude_Lists

Testing will reveal how good this works... :)

Please share the script if it's ready.

Yours, Uwe

Re: New webpage is live

[Uwe Menges]

Dustin J. Mitchell wrote:
 Just a note that the new webpage we previewed a while back is now live:
 
   http://amanda.org/
[...]
 Let us know if you see any problems!


http://amanda.org/ just gives me a dir listing with an f5.txt.

http://www.amanda.org is the normal website.

Maybe adjust the apache config so http://amanda.org works also.

Yours, Uwe

Re: FW: History report?

[Uwe Menges]

stan wrote:
 Beacuse of the ongoing problems we ar having with getting reliable Amanda
 backups here, it has dawned on me that it would be nice to have a report
 showing how old the newest level zero is for each DLE, and so on for wach
 existant level.
 
 Is there an easy way to generate this report?
 

I use amoverview uwe -diskwidth 28 -skipmissed -num0 to get such info.

Yours, Uwe

Trap for the unwary user: split_diskbuffer

[Uwe Menges]

Hi,

I just wanted to report a PEBCAK that I just went into, as reference for 
others.

Short setup description: I wanted to fully backup the 1.5TB on my Linux 
workstation to two 1TB USB hard disks, using amanda 2.6.2alpha-20090130 and 
'tpchanger chg-disk:/backup/amanda', with GNUTAR onto 40GB vtapes (24 slots 
on each USB disk), no holding disk, tape_splitsize 4 gbyte and 
fallback_splitsize 1 gbyte. Of course, I needed a split_diskbuffer for 
splitting, and I put it to /data/scratch.

After roughly 68 hours being afk, I had 1129GB on the USB disks (yes, I'll 
take a look into performance soon). I recognized that the (non-)performance of 
the backup degraded even more in the last 12 hours, and it had merely 64byte/s 
write speed then.

A quick peek with strace showed that the taper process was mainly doing
  getdents64(3, /* 85 entries */, 4096)   = 4080
and I discovered there were 230952 32KB files in /backup/amanda/drive0/data/. 
A sample look at two of them showed that they contained only 0-bytes after the 
header.

After some more digging with the great help of DJ Mitchell on IRC, he gave the 
crucial hint: I didn't exclude the split_diskbuffer location from backup!

Another quick check with ls -l /proc/`pidof taper`/fd/ showed me it was 
really true, the taper was happily reading its own amanda-split-buffer-* files 
(marked as (deleted) but it nevertheless had the file handles), writing them 
again as amanda-split-buffer-* files...

*** So, be sure to have your split_diskbuffer in the exclude list. *** :)

Maybe there will be some fix some day (tar eg. also (now) recognizes its 
currently created archive and won't read it), but I see that this is probably 
not the most urgent part to work on.

Yours, Uwe