linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sam Bull <sam.hacking@sent.com>
To: linux-btrfs@vger.kernel.org
Subject: Questions on incremental backups
Date: Thu, 17 Jul 2014 21:12:58 +0100	[thread overview]
Message-ID: <1405627978.2630.39.camel@s-Air> (raw)

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

I've a couple of questions on incremental backups. I've read the wiki
page, and would like to confirm my understanding of some features, and
also see if other features are possible that are not mentioned. I'm
looking to replace my existing backup solution, and hoping to match the
features I currently use, and go a little beyond.

=== Daily snapshot ===

So, if I understand correctly, I can make a daily snapshot of my
filesystem with very little overhead. Then these can later be synced
efficiently to another system (only syncing the differences), so I can
backup regularly over the internet to my server, and also to an external
HDD. After syncing, I can delete the snapshots (other than the trailing
one needed for the next backup).

In this way I can keep a constant stream of daily backups even when
offline, and simply sync them next time I am online before deleting them
locally.

=== Ignore directories ===

Due to storage limitations on my server, is it possible to ignore
certain directories? For example, ignoring the folder that stores all my
games, as this could be rather large, and the contents can easily be
re-downloaded. The instructions involve subvolumes, so maybe it's
possible to ignore a subvolume when syncing?

If that is possible, then is it also possible to have a separate backup
that does include the ignored directory? For example, having the smaller
sync to the storage-limited server, but having a full sync to an
external HDD.

=== Display backups ===

Is it possible to view the contents of all backups? So, the expected
interface would be something like a tree of all files from across all
snapshots. Any files that are not present in the latest snapshot would
be greyed out to show they have been deleted. Selecting a file would
show a list of versions of the file, with one version for each snapshot
the file has been modified in.

As long as I can get access to this information, maybe some kind of diff
between snapshots, I'm willing to write the actual software to display
this interface. (I suppose even if it's not supported, I could crawl
through the filesystems and generate some kind of database, but that
sounds like a painful process.)

=== Merge snapshots down ===

Is there some way to merge snapshots down? So, I could merge the last
week of daily snapshots into a single weekly snapshot. The new snapshot
should include all files across all the snapshots (even if deleted in
some of the snapshots), and include just the latest version of each
file.

This way, I'd like to maintain daily snapshots, which can be regularly
merged down into weekly snapshots, and then into monthly snapshots, and
then finally into yearly snapshots.


And, finally, there's no problem in deleting old snapshots? I'm assuming
any data from these snapshots used by other snapshots will still be
referenced by the other snapshots, and thus be retained, so nothing will
break?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

             reply	other threads:[~2014-07-17 20:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-17 20:12 Sam Bull [this message]
2014-07-18  4:35 ` Questions on incremental backups Russell Coker
2014-07-18  7:36   ` Bob Williams
2014-07-18 10:45   ` Duncan
2014-07-18 10:55     ` Roman Mamedov
     [not found]     ` <TmvW1o01t4NXQGV01mvYsU>
2014-07-18 12:34       ` Duncan
2014-07-18 13:05         ` Roman Mamedov
2014-07-18 14:28           ` Imran Geriskovan
2014-07-18 12:56   ` Sam Bull
2014-07-18 13:40     ` Russell Coker
2014-07-18 14:27       ` Mike Hartman
2014-07-20 16:56         ` Sam Bull
2014-07-18 17:31       ` Daniel Mizyrycki

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=1405627978.2630.39.camel@s-Air \
    --to=sam.hacking@sent.com \
    --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).