Hi,
As far as i recal this is an expected behavior for this version of amanda.
short explanation:
amcheck does all work as normal user, so if the user hasn't access to
the full tree up to the root dir it will complain it can't access these
dirs.
amdump does the backups with elevated rights, so it can access these
dirs without a problem.
That isn't nice but i have learned to live with it....
Cu Christoph
Am 21.06.19 um 16:00 schrieb Gene Heskett:
I sent this yesterday around noon, but it never came back. I've also
appended additional info at the bottom.
====resent msg=====
I just installed the stretch version of amanda common and amanda client,
with should have restored one of my machines to a full
backup status.
Unforch, it didn't, and this situtation existed on the previous jessie
install, where a pi scatters its stuff over a larg e number
of mount points all attached to /, so basically nothing has actually
changed.
But here is the emailed report from last nights run:
STRANGE DUMP DETAILS:
/-- picnc / lev 0 STRANGE
sendbackup: start [picnc:/ level 0]
sendbackup: info BACKUP=/bin/tar
sendbackup: info RECOVER_CMD=/bin/tar -xpGf - ...
sendbackup: info end
? /bin/tar: ./dev: directory is on a different filesystem; not dumped
? /bin/tar: ./proc: directory is on a different filesystem; not dumped
? /bin/tar: ./run: directory is on a different filesystem; not dumped
? /bin/tar: ./sys: directory is on a different filesystem; not dumped
? /bin/tar: ./media/pi/backuppi: directory is on a different
filesystem; not dumped
? /bin/tar: ./media/pi/bootpi: directory is on a different filesystem;
not dumped
? /bin/tar: ./media/pi/workpi1: directory is on a different filesystem;
not dumped
? /bin/tar: ./media/pi/workpi120: directory is on a different
filesystem; not dumped
| /bin/tar: ./tmp/.X11-unix/X0: socket ignored
| /bin/tar: ./tmp/ssh-5i6ERjqwMXjX/agent.705: socket ignored
| /bin/tar: ./tmp/ssh-VqldgesfylC3/agent.611: socket ignored
| Total bytes written: 8424396800 (7.9GiB, 5.2MiB/s)
sendbackup: size 8226950
sendbackup: end
\--------
==============
then in the actual report:
==============
picnc / 0 8034 3685 45.9 25:48 5314.9
0:25 150937.9
picnc /boot 1 36 29 79.8 0:05 7168.4
0:00 295570.0
That level 0 should have been around 7 or 8GB. The 1st 4 shoulda been
in the excludes file and I can fix that easy nuff, as should the last 3.
But it looks as if I'll have to make disklist entries for the pair of
ssd's plugged into /media.
But thats not legal either: amcheck says:
ERROR: picnc: Could not access /media/pi/workpi120 (/media/pi/workpi120):
Permission denied
ERROR: picnc: Could not access /media/pi/bootpi (/media/pi/bootpi):
Permission denied
ERROR: picnc: Could not access /media/pi/backuppi (/media/pi/backuppi):
Permission denied
ERROR: picnc: Could not access /media/pi/workpi1 (/media/pi/workpi1):
Permission denied
/media is owned by root:root, but everything beyond that is pi:pi who is
1st
user on picnc.coyote.den
What changed to cause this sudden fussiness? Better yet, how do I fix
this?
=========end resent========
There seems to a marked disagreement between amanda and amanda.
After it has logged the no perms errors above, then at the end of the
body of that same message (and this is after I had added those 4
locations as separate LDE's, I see this in the same run report:
picnc /media/pi/backuppi 0 0 0 -- 0:01 8.9
0:00 0.0
picnc /media/pi/bootpi 0 0 0 -- 0:00 72.9
0:00 0.0
picnc /media/pi/workpi1 0 2603 817 31.4 5:45 7734.3
0:08 104628.4
picnc /media/pi/workpi120 0 0 0 -- 0:01 8.3
0:00 0.0
Which looks perfectly normal since there is not in fact anything on 3 of
those partitions/directories, its two separate SSD's, on usb adaptors
plugged into that pi-3b.
Twould be nice if stories matched. Helpful even.
Cheers, Gene Heskett
