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

[Greg Troxel]

Grant <address@hidden> writes:

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

No.  If the block is bad, writing will usually reallocate or fail.  The
worry is that the bits have gone bad on the client, but you haven't noticed.

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

yes, at least periodically.

> We can't just use fsck on the HD to check for corruption?

because that checks metadata and doesn't check if the bits have silently
changed.

I had a system with 2 drives in RAID1 (NetBSD raidframe).  I found some
images were damaged.  It turned out that for many of them one of the
raid mirrors was ok and the other was not.   I ended up concluding that
the RAM was bad.  Once replaced, all was well.