Re: [rdiff-backup-users] Incremental Restore

[Edward Ned Harvey]

> From: Kosta Welke [mailto:address@hidden
> Sent: Monday, May 06, 2013 1:26 PM
> 
> > Out of curiosity, what are you moving to?
> 
> I'm currently trying out btrfs, as it has the easiest upgrade path for me
and
> seems to allow a "RAID 1" that consists of one 2TB drive and 3 500GB
drives,
> resulting in a 1.5TB raid (wasting half a GB).

So ... for what it's worth ... I loves me some COW, and I'm psyched for
btrfs, and maybe it's actually ready to use by now, because it's developing
so rapidly, that my latest understanding over the last year might have
become obsolete already...  But...

As I understand it, at present, "df" doesn't fully understand btrfs raid-1.
Btrfs raid-1 is sort of like raid-1e, where it intelligently stores 2 copies
of every block on independent disks, but you don't know which disks.  "df"
on a btrfs volume shows the free space in the volume, but doesn't know, that
when you write 1MB, you will lose 2MB from your free space.  Also, if you
happen to fill up those 3x 500G drives and still have 1.5T avail on your 2T
drive, df will show 1.5T avail, and when you try to write, you get "no
available disk space." or something.

So I don't think you're seeing what you think you're seeing.  But in any
event, more comments below...


> Doesn't the `rdiff-backup --force -r $INC /rdiff-backup-dir/
/tmp/staging/`
> step do a full checkout? That is the step I want to avoid as one checkout
is >
> 100 GB. That takes forever and is the main motivation for me fiddle around
> with the incremental stuff. The backup and the destination different hard
> drives inside the same machine.

Yes.  That's why I said I'm sure there's a more space and time efficient
solution possible...  But ... 

Trying to parse through the "increments" subdir is tricky.  If you get it
right, you can save some time and space (but you'll probably waste that much
time figuring out how to get it right, and you'll have higher risk of
getting something wrong.)


> Thanks for the `sed` magic though, my bash/unix utils skills are a bit
rusty.

Especially if your bash/unix utils skills are rusty.   ;-)
The safer thing to do is to give it the time & space to do the restores the
slow and easy way...

It's also very easy to accidentally forget about the final timestamp, or
handle it wrongly, because (a) it's not displayed directly by the -l switch,
and (b) if you "ls" the rdiff-backup-dir, you don't directly see it there
either.

Overclock at your own risk.    ;-)