Hi, could it be the level 1 dump on Homenet005 was taken after the files were deleted? if so this is correct behavior. When tar is used with the --listed-incremental option it does not only backup new or changed files, it also takes care of deleted files since the last level 0 and deletes these files if they are on disk...... That is completley correct behavior. if you do not want these files to be removed, go and look when in your dumpcycle between tape Homenet002 and tape Homenet005 they were deleted and then in amrecover do a setdate to the day before that day. After this amrecover will restor the filesystem to the state it was in at that day, not to the default (the last run). Hope it helps Christoph
Marc N. Cannava wrote: > I have a strange problem affecting my Amanda installation, I have looked > high and low for the solution but I haven't seen anyone with quite this > problem.. > > I am backing up two Linux machines and one PC. One day I decided to do a > test restore to see if everything was going well. > > I picked a filesystem on the PC to restore, one that is relatively quiet > -- so the incremental backups most likely contain nothing, since the > files never change. > > The machine's name is runabout, and its entry in the Amanda server's > disklist looks like this: > > sevenof9 //runabout/D$ root-tar -1 local > > "sevenof9" is the Amanda server machine, runabout is the remote PC. > > So I run amrecover on sevenof9, do a "setdisk //runabout/D$", then do > "select Photos", which is a directory on the D drive I want to restore. > > Then I start the restore with 'extract'. > > Amanada, during the restore, asks for two tapes -- Homenet002 (the last > level 0) and Homenet005 (the last level 1). This makes sense. > > It restores the files from the level 0 fine -- I see it extract the > files onto the local disk, and in the debug file I see that it did this: > > amrecover: stream_client: connected to 192.168.0.50.10083 > amrecover: stream_client: our side is 0.0.0.0.895 > amrecover: try_socksize: receive buffer size is 65536 > Started amidxtaped with arguments "6 -h -p /dev/nst0 sevenof9 > ^//runabout/D\$$ 20020606" > Exec'ing /bin/gtar with arguments: > tar > -xpGvf > - > ./Photos > > Fine. Then amrecover asks me to load tape Homenet005, which I do, and it > whirs a little bit and says this: > > Load tape homenet005 now > Continue? [Y/n]: > ./Photos/ > tar: Deleting `./Photos/NewYears 2002' > ./Photos/NewYears 2002/ > amrecover> quit > > Sure enough, tar DELETED "./Photos/NewYears 2002" !!!! > > At the end of the restore, I have *NO* files left! > > The debug file shows this, for the second extraction from the level 1 > tape: > > amrecover: stream_client: connected to 192.168.0.50.10083 > amrecover: stream_client: our side is 0.0.0.0.870 > amrecover: try_socksize: receive buffer size is 65536 > Started amidxtaped with arguments "6 -h -p /dev/nst0 sevenof9 > ^//runabout/D\$$ 20020609" > Exec'ing /bin/gtar with arguments: > tar > -xpGvf > - > ./Photos > amrecover: pid 4184 finish time Sun Jun 9 20:14:27 2002 > > How can this be, and why is Amanda doing this to me? > > Thanks so much in advance! > > \marc > > >
