Re: [rdiff-backup-users] Incremental, automated, remote, secure

[Dominic Raferd]

On 18/07/2013 17:39, Grant wrote:
> > Basically run dump or something on the client, to a holding disk file on
> > the server with the tape.   I don't see any issue with temporary disk
> > use.  The point is that all the temp bits are written anew each time,
> > not assumed to be the same based on metadata.
> So what we are trying to avoid is always copying data from the client
> to the same blocks on the server's HD before copying to tape?  We want
> to copy to random blocks on the server each time so we aren't always
> stuck with the same bad blocks?
>
> And you don't try to maintain a special (rdiff-backup, rsnapshot, etc)
> repository on tape, you just keep recording full copies and changing
> tapes?
>
> We can't just use fsck on the HD to check for corruption?

There is logic in having a simple ol' backup under lock and key, but I 
would say do that alongside rdiff-backup for onsite backup, replicated 
offsite with rsync. Yes there is a theoretical risk of corruption of the 
primary (onsite) backup (which would then be replicated offsite), but 
rdiff-backup always stores the most recent backup set in the clear and 
this would be quite easy to verify against the source data with rsync 
using -c (checksum) option.

For older version of files (or a file that no longer exists on the 
source) the risk of corruption increases I admit. rdiff-backup does 
offer a verification routine for earlier backups but I believe you 
should run it for each separate backup sequentially to have high 
confidence that all data is recoverable. I have a script which can help 
with this.

In practice I don't do this regularly but using rdiff-backup I have 
recovered database files from 6 months ago that have subsequently been 
backed-up daily and have changed each day. The thought of going from the 
current backup and applying each reverse-delta file sequentially to 
recover the version that existed 180 days ago makes my brain hurt, but 
rdiff-backup has patched it all up seamlessly...

Dominic
http://www.timedicer.co.uk