* Jean-Louis Martineau <jmartin...@carbonite.com> [20170202 11:10]: > You can't do a level 1 backup if there is no state file for the level 0 > (full) backup. > > Force a full backup of the dle with amadmin CONF force HOST DISK
Of course, it makes sense! Thanks, jf > > Jean-Louis > > On 02/02/17 11:05 AM, Jean-Francois Malouin wrote: > > * Jean-Louis Martineau <jmartin...@carbonite.com> [20170202 10:52]: > >> Do amcheck reported an error? > > amcheck returns fine. > > > >> $ man ambsdtar > >> STATE-DIR > >> > >> The directory where ambsdtar stores the database it uses to > >> generate incremental dumps. The default is set when Amanda is > >> built. > >> > >> > >> Create the /usr/local/share/amanda/bsdtar directory of set the property > >> STATE-DIR to another directory that exists. > > As I said, the state-dir /usr/local/share/amanda/bsdtar *already* exists > > on the client but is empty at the moment as I didn't put back the files > > that amanda/bsdtar created *before* I rebuilt the VM. If I leave the > > state dir empty, who should own it and what should the permissions be? > > > > Right now: > > > > # ls -ld /usr/local/share/amanda/bsdtar > > drwxr-xr-x 2 amanda amanda 512 Feb 2 09:29 > > /usr/local/share/amanda/bsdtar > > > > thanks, > > jf > > > > > > > >> Jean-Louis > >> > >> > >> On 02/02/17 10:12 AM, Jean-Francois Malouin wrote: > >>> Hi, > >>> > >>> I've got this VM running FreeBSD-11 and amanda-client-3.3.6 installed on > >>> it for testing purposes. Server is 3.4.1. Initial tests worked ok > >>> (backups and restores) but I had to rebuild the VM from scratch for > >>> whatever reasons. After reinstalling and configuring amanda on it as I > >>> previously did, the amanda backup run on it fails with this in the > >>> amreport: > >>> > >>> > >>> FAILED DUMP DETAILS: > >>> /-- 172.16.10.104 /ifs lev 1 FAILED [missing size line from > >>> sendbackup] > >>> sendbackup: info BACKUP=APPLICATION > >>> sendbackup: info APPLICATION=ambsdtar > >>> sendbackup: info > >>> RECOVER_CMD=/usr/local/libexec/amanda/application/ambsdtar restore > >>> [./file-to-restore]+ > >>> sendbackup: info end > >>> ? ambsdtar: error opening > >>> /usr/local/share/amanda/bsdtar/172.16.10.104_ifs_0: No such file or > >>> directory > >>> ? dumper: strange [missing size line from sendbackup] > >>> \-------- > >>> > >>> client debug file shows: > >>> > >>> Wed Feb 1 21:30:32 2017: thd-0x800718e00: ambsdtar: pid 40453 ruid 0 > >>> euid 140 version 3.3.6: start at Wed Feb 1 21:30:32 2017 > >>> Wed Feb 1 21:30:32 2017: thd-0x800718e00: ambsdtar: version 3.3.6 > >>> Wed Feb 1 21:30:32 2017: thd-0x800718e00: ambsdtar: pid 40453 ruid 0 > >>> euid 140 version 3.3.6: rename at Wed Feb 1 21:30:32 2017 > >>> Wed Feb 1 21:30:32 2017: thd-0x800718e00: ambsdtar: BSDTAR-PATH > >>> /usr/bin/bsdtar > >>> Wed Feb 1 21:30:32 2017: thd-0x800718e00: ambsdtar: STATE-DIR > >>> /usr/local/share/amanda/bsdtar > >>> Wed Feb 1 21:30:32 2017: thd-0x800718e00: ambsdtar: ONE-FILE-SYSTEM yes > >>> Wed Feb 1 21:30:32 2017: thd-0x800718e00: ambsdtar: SIZE ^ *Total bytes > >>> written: [0-9][0-9]* > >>> Wed Feb 1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE : Directory > >>> is new$ > >>> Wed Feb 1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE : Directory > >>> has been renamed > >>> Wed Feb 1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE file changed > >>> as we read it$ > >>> Wed Feb 1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^could not > >>> open conf file > >>> Wed Feb 1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^Elapsed time: > >>> Wed Feb 1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^Throughput > >>> Wed Feb 1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : File .* > >>> shrunk by [0-9][0-9]* bytes, padding with zeros > >>> Wed Feb 1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : Cannot add > >>> file .*: No such file or directory$ > >>> Wed Feb 1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : Error exit > >>> delayed from previous errors > >>> Wed Feb 1 21:30:32 2017: thd-0x800718e00: ambsdtar: STRANGE : socket > >>> ignored$ > >>> Wed Feb 1 21:30:32 2017: thd-0x800718e00: ambsdtar: ambsdtar: error > >>> opening /usr/local/share/amanda/bsdtar/172.16.10.104_ifs_0: No such file > >>> or directory > >>> > >>> But /usr/local/share/amanda/bsdtar exists on the client (although empty > >>> at the moment) and has the ownership and permissions: > >>> > >>> # ls -la /usr/local/share/amanda/bsdtar > >>> total 24 > >>> drwxr-xr-x 2 amanda amanda 512 Feb 2 09:29 . > >>> drwxr-xr-x 5 root wheel 512 Feb 1 16:32 .. > >>> > >>> I'm kind of lost as to why this worked in the first place and now > >>> fails...what should be the ownership and permissions on it? > >>> > >>> Looking back at the restores on the server of the successful backups of > >>> /usr/local on this client I can see the bsdtar state files in there with > >>> the permissions: > >>> > >>> /restore/sim/share/amanda/bsdtar# ls -la > >>> total 24 > >>> drwxr-xr-x 2 140 140 4096 Feb 2 09:25 ./ > >>> drwxr-xr-x 5 root root 144 Jan 19 07:57 ../ > >>> -rw------- 1 140 140 24 Jan 20 16:33 172.16.20.104_ifs_0 > >>> -rw------- 1 140 140 24 Jan 22 16:31 172.16.20.104_ifs_1 > >>> -rw------- 1 140 140 24 Jan 24 16:32 172.16.20.104_ifs_2 > >>> -rw------- 1 140 140 24 Jan 20 16:32 172.16.20.104_usr_local_0 > >>> -rw------- 1 140 140 24 Jan 24 16:31 172.16.20.104_usr_local_1 > >>> > >>> 140 is the amanda user UID and GID on the client: > >>> > >>> # id amanda > >>> uid=140(amanda) gid=140(amanda) groups=140(amanda),5(operator) > >>> > >>> Thanks, > >>> jf
