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 _______________________________________________ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
