[Discuss] Disk recovery utilities - dealing with deleted files

[gaf at blu.org (Jerry Feldman)]

On 02/04/2013 08:07 PM, Edward Ned Harvey (blu) wrote:
>> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss-
>> bounces+blu=nedharvey.com at blu.org] On Behalf Of Rich Braun
>>
>> Lesson learned: obviously, I'm going to change that cron job to some sort of
>> sequestration method:  move the files someplace before this rsync, don't
>> ever
>> delete them until I manually confirm. (Anyone else have a script for that?
>> It'll be a bit hairy to write from scratch...)
> If the destination supports it, I would highly recommend rsnapshot.  Or better yet, zfs.  ;-)  But seriously, given that you're currently using rsync, there's a very good chance you can support rsnapshot, which is rsync-based and works great.  (Albeit confusing to configure the first time.)
>
I use rsnapshot at home to back up my entire Linux system as well as the
BLU mail server. The nice thing about using an rsync-based system is
that you have a directory that is already in standard Linux format. What
rsnapshot brings to the table is incremental backups with full Linux
directory structures, using hard links to link duplicate files using the
--link-dest parameter. Back in the old days I used tar(1) but it picked
up an oversized file (a VM) and half of my archive was unavailable (this
was on a 32-bit system at the time).

Before big blue bought our company we used rsnapshot very successfully
to a very slow WD Mybook. While the backups would take forever, if I
ever needed to get a backed up file, it would take just a few minutes.
With many backup systems extracting a single file can be a real pain.

rsnapshot does have a few downsides. First you are keeping an entire
Linux directory uncompressed so space is an issue on larger systems,
secondly, if the backup fails you might have an incomplete archive.
Assuming you have multiple backup directories, you would still have the
previous archive, but on the next backup, the new directory will have
lost some of the hard links resulting in some duplicate files. Because
of the WD Mybook space and slowness, I would rename the partial
directory to a unique name to be deleted, and manually perform a
rollback, so the next backup would establish the hard links.

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90 
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90