linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Shriramana Sharma <samjnaa@gmail.com>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Using BtrFS and backup tools for keeping two systems in sync
Date: Thu, 8 Oct 2015 07:26:11 -0400	[thread overview]
Message-ID: <561652D3.1020606@gmail.com> (raw)
In-Reply-To: <CAH-HCWV2mO1FFRGPh+jh2TrZMYV-7w7MwytSV4WZ33-9PW=qRw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1834 bytes --]

On 2015-10-07 22:35, Shriramana Sharma wrote:
> Hello. I see there are some backup tools taking advantage of BtrFS's
> incremental send/receive feature:
> https://btrfs.wiki.kernel.org/index.php/Incremental_Backup. [BTW Ames
> Cornish's ButterSink (https://github.com/AmesCornish/buttersink) seems
> to be missing from that page.]
>
> Now I'd like to know if anyone has evolved some good practices w.r.t
> maintaining the data of two systems in sync using this feature of
> BtrFS. What I have in mind is: I work on my desktop by default, and
> for ergonomics reasons only use my laptop when I need the mobility.
> I'd like to keep the main data (documents I create, programs I write
> etc) in sync between the two. (The profile data such as in the ~/.*
> hidden folders had better stay separate though, I guess.)
>
> I figure with the existing tools it would not be too difficult to
> maintain a synced set of snapshots between the two systems if I only
> use the desktop vs laptop alternatingly and sync at each switchover,
> but the potential problem only would come if I modify both (something
> like having to do git merge, I guess).
>
> Has anyone come across this situation and evolved any policies to handle it?
>
Personally, while I use BTRFS on all of my systems, I usually use 
Dropbox for synchronizing data between them.  While the Linux client for 
it isn't perfect, it is significantly easier than something like a 
regularly scheduled rsync or btrfs send/receive.  It's also kind of nice 
because multiple clients bound to the same account will sync across the 
local network without needing to talk to the servers if they can avoid 
it.  Of course, it costs money if you want a decent amount of storage 
space, but it's pretty reasonable for the degree of reliability I've 
observed.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

      parent reply	other threads:[~2015-10-08 11:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-08  2:35 Using BtrFS and backup tools for keeping two systems in sync Shriramana Sharma
     [not found] ` <CAC=t97ABS4+D4FczYi8Vk9FKxJkwySccDYVzDhyj2Tj3rDOtJA@mail.gmail.com>
2015-10-08  5:54   ` Shriramana Sharma
2015-10-08  6:37 ` Hugo Mills
2015-10-08 23:18   ` Duncan
2015-10-08 11:26 ` Austin S Hemmelgarn [this message]

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=561652D3.1020606@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=samjnaa@gmail.com \
    /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).