Amanda-Users

Re: Incorrect bahaviour causes backup loss !!

2006-07-27 12:26:06
Subject: Re: Incorrect bahaviour causes backup loss !!
From: "Alan Pearson" <alandpearson AT yahoo DOT com>
To: amanda-hackers AT amanda DOT org
Date: Thu, 27 Jul 2006 17:18:32 +0100 (BST)
On Thu, July 27, 2006 4:42 pm, Jon LaBadie wrote:
> On Thu, Jul 27, 2006 at 04:07:40PM +0100, Alan Pearson wrote:
>> Guys,
>>
>> I'm running amanda 2.5.0p2.
>>
>> Last night, I got the following report from amdump (relevant lines
>> extracted) :
>>
>> FAILED AND STRANGE DUMP DETAILS:
>>
>> /--  qtvpdc / lev 2 STRANGE
>> sendbackup: start [qtvpdc:/ level 2]
>> sendbackup: info BACKUP=/usr/bin/gnutar
>> sendbackup: info RECOVER_CMD=/usr/bin/gnutar -f... -
>> sendbackup: info end
>> ? gtar: ./Library/Logs/PasswordService/ApplePasswordServer.Server.log.
>> 1: file changed as we read it
>> | Total bytes written: 912343040 (871MiB, 3.9MiB/s)
>> sendbackup: size 890960
>> sendbackup: end
>> \--------
>>
>> NOTES:
>>   planner: Last full dump of qtvpdc:/ on tape DailySet1-3
>> overwritten on this run.
>>   planner: Incremental of qtvpdc:/ bumped to level 2.
>>   planner: qtvpdc / 20060727 0 [dump larger than available tape
>> space, 35448530 KB, full dump delayed]
>>
>>
>>
>>
>>
>>
>> In the NOTES section it says that a full dump of the machine qtvpdc
>> was delayed because it was larger than available tape space.
>> Yet it says it is going to overwrite the last full dump of this
>> machine 2 lines previous.
>>
>> Today a user came and asked me to restore a file from a few days back
>> from this machine. I can't because Amanda blew away the last full
>> backup.
>> When Amanda realises it's going to blow away the only full backup of
>> a machine still in it's disklist, it should be a LOT clever than this.
>>
>> Yes I realise it wouldn't fit on the tape, but Amanda should at least
>> have put it in the holding disk area or NOT overwritten the only full
>> backup at all.
>>
>> Maybe a compromise, leave the backup in the holding disk, and backup
>> the other stuff that will fit to tape.
>
> That would seem to be a hard call.  For just one example, I've got
> a DLE that I only do weekly full dumps, no incrementals.  It contains
> nothing but *.iso files, dvd or cd images, that I can easily recreate
> from the original optical media.  And some of my DLEs go directly
> to tape, bypassing the holding disk.  Should the backup of those
> direct to tape DLEs be skipped to preserve my relatively unimportant
> last full dump of the *.iso DLE?
>


I'd suggest that the last full dump is NEVER overwritten, regardless.
Amanda can't be expected to know the importance of one backup to another.
If it's important enough to backup, then it's important !

I realise it is a difficult call, but something needs to be done to
prevent this from happening.
I also expected a few comments on it !


> Just for info, how did you get to the situation of only having one
> full dump in the tapecycle?  If that tape failed you would have
> been in a similar situation.  Failed tapes were pretty common for
> me when I was using DDS tapes.  Typically I have 3-5 full dumps
> within a tapecycle.  (Not counting those in the archive config)
>


It happened because some large files were added in between amcheck and
amdump, and over the past month more machines added, taking us nearer the
tape capacity. I will add more tapes (when they arrive !!), but it _could_
still happen, and I believe it should NEVER be allowed to happen that you
get into a state where you don't have a full backup of the machine.



Cheers,
AlanP