[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dominic Raferd
Subject: Re: [rdiff-backup-users] Incremental, automated, remote, secure
Date: Fri, 19 Jul 2013 16:44:01 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7

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

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...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]