From: Roman Mamedov <rm@romanrm.net>
To: Dave <davestechshop@gmail.com>
Cc: Linux fs Btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Need help with incremental backup strategy (snapshots, defragmentingt & performance)
Date: Tue, 14 Nov 2017 13:50:40 +0500 [thread overview]
Message-ID: <20171114135040.65a659c0@natsu> (raw)
In-Reply-To: <CAH=dxU56geiO7MuWSbPgpfBQ3vbkPYm6juQZzu3-1=-RzG+ZSQ@mail.gmail.com>
On Mon, 13 Nov 2017 22:39:44 -0500
Dave <davestechshop@gmail.com> wrote:
> I have my live system on one block device and a backup snapshot of it
> on another block device. I am keeping them in sync with hourly rsync
> transfers.
>
> Here's how this system works in a little more detail:
>
> 1. I establish the baseline by sending a full snapshot to the backup
> block device using btrfs send-receive.
> 2. Next, on the backup device I immediately create a rw copy of that
> baseline snapshot.
> 3. I delete the source snapshot to keep the live filesystem free of
> all snapshots (so it can be optimally defragmented, etc.)
> 4. hourly, I take a snapshot of the live system, rsync all changes to
> the backup block device, and then delete the source snapshot. This
> hourly process takes less than a minute currently. (My test system has
> only moderate usage.)
> 5. hourly, following the above step, I use snapper to take a snapshot
> of the backup subvolume to create/preserve a history of changes. For
> example, I can find the version of a file 30 hours prior.
Sounds a bit complex, I still don't get why you need all these snapshot
creations and deletions, and even still using btrfs send-receive.
Here is my scheme:
============================================================================
/mnt/dst <- mounted backup storage volume
/mnt/dst/backup <- a subvolume
/mnt/dst/backup/host1/ <- rsync destination for host1, regular directory
/mnt/dst/backup/host2/ <- rsync destination for host2, regular directory
/mnt/dst/backup/host3/ <- rsync destination for host3, regular directory
etc.
/mnt/dst/backup/host1/bin/
/mnt/dst/backup/host1/etc/
/mnt/dst/backup/host1/home/
...
Self explanatory. All regular directories, not subvolumes.
Snapshots:
/mnt/dst/snaps/backup <- a regular directory
/mnt/dst/snaps/backup/2017-11-14T12:00/ <- snapshot 1 of /mnt/dst/backup
/mnt/dst/snaps/backup/2017-11-14T13:00/ <- snapshot 2 of /mnt/dst/backup
/mnt/dst/snaps/backup/2017-11-14T14:00/ <- snapshot 3 of /mnt/dst/backup
Accessing historic data:
/mnt/dst/snaps/backup/2017-11-14T12:00/host1/bin/bash
...
/bin/bash for host1 as of 2017-11-14 12:00 (time on the backup system).
============================================================================
No need for btrfs send-receive, only plain rsync is used, directly from
hostX:/ to /mnt/dst/backup/host1/;
No need to create or delete snapshots during the actual backup process;
A single common timeline is kept for all hosts to be backed up, snapshot count
not multiplied by the number of hosts (in my case the backup location is
multi-purpose, so I somewhat care about total number of snapshots there as
well);
Also, all of this works even with source hosts which do not use Btrfs.
--
With respect,
Roman
next prev parent reply other threads:[~2017-11-14 8:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-01 5:00 Need help with incremental backup strategy (snapshots, defragmentingt & performance) Dave
2017-11-01 5:15 ` Roman Mamedov
2017-11-01 6:27 ` Dave
2017-11-14 3:39 ` Dave
2017-11-14 7:14 ` Marat Khalili
2017-11-14 8:21 ` Roman Mamedov
2017-11-14 8:50 ` Roman Mamedov [this message]
2017-11-14 20:51 ` Dave
2017-11-16 16:10 ` Kai Krakow
2017-11-16 16:13 ` Kai Krakow
2017-11-17 3:51 ` Andrei Borzenkov
2017-11-17 22:36 ` Kai Krakow
2017-11-01 6:19 ` Marat Khalili
2017-11-01 6:51 ` Dave
2017-11-01 8:34 ` Marat Khalili
2017-11-01 20:27 ` Dave
2017-11-02 0:35 ` Peter Grandi
2017-11-02 20:46 ` Kai Krakow
2017-11-03 3:24 ` Dave
2017-11-03 7:06 ` Kai Krakow
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=20171114135040.65a659c0@natsu \
--to=rm@romanrm.net \
--cc=davestechshop@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.