linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Backup: Compare sent snapshots
Date: Sun, 30 Mar 2014 22:41:59 +0000 (UTC)	[thread overview]
Message-ID: <pan$92371$cf7e2c62$a94a9382$e3e154b@cox.net> (raw)
In-Reply-To: 8465933.4bvG1Xk5zJ@linuxpc

GEO posted on Sun, 30 Mar 2014 10:58:13 +0200 as excerpted:

> Hi,
> 
> I am doing backups regularly following the scheme of
> https://btrfs.wiki.kernel.org/index.php/Incremental_Backup

Be aware that send/receive is getting a lot of attention and bugfixes 
ATM.  To the best of my knowledge, where it completes without error it's 
100% reliable, but there are various corner-cases where it will presently 
trigger errors.  So I'd have a fallback backup method ready, just in case 
it quits working, and wouldn't rely in it working at this point.  (Altho 
with all the bug fixing it's getting ATM, it should be far more reliable 
in the future.)

FWIW, the problems seem to be semi-exotic cases, like where subdirectory 
A originally had subdir B nested inside it, but then that was reversed, 
so A is now inside B instead of B inside A.  Send/receive can get a bit 
mixed up in that sort of case, still.

> It states we keep a local reference of the read only snapshot we sent to
> the backup drive, which I understand.
> But now I have a question:  When I do a read only snapshot of home, send
> the difference to the backup drive, keep it until the next incremental
> step, send the difference to the backup drive, remove the old read only
> snapshot and so on...
> I wonder what happens if the read only snapshot I keep as a local
> reference got corrupted somehow.
> Then maybe too much difference would be sent which would not be
> dramatic, or too less, which would be.

In general, it wouldn't be a case of too much or too little being sent.  
It would be a case of send or receive saying, "Hey, this no longer makes 
sense, ERROR!"

But as I said above, as long as both ends are completing without error, 
the result should be fully reliable.

> Is there a quick way I could compare the last sent snapshot to the local
> one, to make sure the local reference is still the same?

A checksum of all content (including metadata), using md5sum or the like, 
on both ends.  Or do a checksum and keep a record of the result, 
comparing a later result to the previous one for the same snapshot.

As for what to actually do that checksum on, I'll let someone with more 
knowledge and experience speak up there.

> Apart from that, imagine I somehow lost the local reference (e.g. delete
> it by mistake), would there still be a way to sync the difference to the
> last sent snapshot on the backup device?

Two possibilities:

1) Reverse the send/receive, sending it from the backup to the working 
instance, thereby recreating the missing snapshot.

2) Keep more than one snapshot on each end, with the snapshot thinning 
scripts kept in sync.

So if you're doing hourly send/receive, keep the latest three, plus the 
one done at (say) midnight for each of the previous two days, plus the 
midnight snapshot for say Saturday night for the last four weeks, being 
sure to keep the same snapshots on both ends.

That way, if there's a problem with the latest send/receive, you can try 
doing a send/receive against the two hour ago or two day ago base, 
instead of the one from an hour ago.  If that doesn't work, you can try 
reversing the send/receive, sending from the backup.

But as I said, do be prepared for send/receive bugs and the errors they 
trigger.  If you hit one, you may have to fall back to something more 
traditional such as rsync, presumably reporting the bug and keeping the 
last good received snapshots around as a reference so you can try again 
with test patches or after the next kernel upgrade.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


  reply	other threads:[~2014-03-30 22:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-30  8:58 Backup: Compare sent snapshots GEO
2014-03-30 22:41 ` Duncan [this message]
2014-09-26 16:15   ` G EO
2014-09-27  4:17     ` Duncan
2014-09-27 10:01       ` G EO
2014-09-28  4:31         ` Duncan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='pan$92371$cf7e2c62$a94a9382$e3e154b@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).