Re: [rdiff-backup-users] Incremental Restore

[Kosta Welke]

Hi!

On May 7, 2013, at 24:30 , Edward Ned Harvey wrote:

> As I understand it, at present, "df" doesn't fully understand btrfs raid-1.

I'll see how it works when I get there. I tried to get a better understanding 
of this by reading the btrfs FAQ on the wiki and the man pages, but now I'm 
only more confused :)

>> Doesn't the `rdiff-backup --force -r $INC /rdiff-backup-dir/
> /tmp/staging/`
>> step do a full checkout?

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

Yeah but those full checkouts take forever. However, the actual reason why I 
didn't want to do full checkouts is that I feared that this would not allow 
copy-on-write and the btrfs deduplication sounds rather... experimental. 

So I think full checkout to temp restore directory && rsync -a --delete is the 
way to go here.

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

In any case, after all rsync backups are through, I will do an rsync -a 
--delete from the actual directory (NOT the rdiff-backup storage) to the new 
disk. But thanks for the heads-up: This means I'll have to do a restore from 
`now` after all increments. I wouldn't have done that otherwise.

On May 7, 2013, at 08:38 , Adrian A. Baumann wrote:

> I'd do an "rsync -a --delete /tmp/staging/ /destination" - otherwise, you'll 
> end up with all the deleted files restored as well.

Thanks! That's actually the big reason to go for "full restore" of each 
increment. I feel that I could easily write that code, but my gut feeling is 
that that would reach a complexity where I would screw up somewhere and only 
notice after it's too late. 

Cheers,
Kosta