From: Kai Krakow <hurikhan77@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: Need help with incremental backup strategy (snapshots, defragmentingt & performance)
Date: Thu, 2 Nov 2017 21:46:13 +0100 [thread overview]
Message-ID: <20171102214613.10af365e@jupiter.sol.kaishome.de> (raw)
In-Reply-To: CAH=dxU7APYANHn3PjqepY9dr9F3RRhzE1OSgtar9tN-74haS9g@mail.gmail.com
Am Wed, 1 Nov 2017 02:51:58 -0400
schrieb Dave <davestechshop@gmail.com>:
> >
> >> To reconcile those conflicting goals, the only idea I have come up
> >> with so far is to use btrfs send-receive to perform incremental
> >> backups
> >
> > As already said by Romain Mamedov, rsync is viable alternative to
> > send-receive with much less hassle. According to some reports it
> > can even be faster.
>
> Thanks for confirming. I must have missed those reports. I had never
> considered this idea until now -- but I like it.
>
> Are there any blogs or wikis where people have done something similar
> to what we are discussing here?
I used rsync before, backup source and destination both were btrfs. I
was experiencing the same btrfs bug from time to time on both devices,
luckily not at the same time.
I instead switched to using borgbackup, and xfs as the destination (to
not fall the same-bug-in-two-devices pitfall). Borgbackup achieves a
much higher deduplication density and compression, and as such also is
able to store much more backup history in the same storage space. The
first run is much slower than rsync (due to enabled compression) but
successive runs are much faster (like 20 minutes per backup run instead
of 4-5 hours).
I'm currently storing 107 TB of backup history in just 2.2 TB backup
space, which counts a little more than one year of history now,
containing 56 snapshots. This is my retention policy:
* 5 yearly snapshots
* 12 monthly snapshots
* 14 weekly snapshots (worth around 3 months)
* 30 daily snapshots
Restore is fast enough, and a snapshot can even be fuse-mounted (tho,
in that case mounted access can be very slow navigating directories).
With latest borgbackup version, the backup time increased to around 1
hour from 15-20 minutes in the previous version. That is due to
switching the file cache strategy from mtime to ctime. This can be
tuned to get back to old performance, but it may miss some files during
backup if you're doing awkward things to file timestamps.
I'm also backing up some servers with it now, then use rsync to sync
the borg repository to an offsite location.
Combined with same-fs local btrfs snapshots with short retention times,
this could be a viable solution for you.
--
Regards,
Kai
Replies to list-only preferred.
next prev parent reply other threads:[~2017-11-02 20:46 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
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 [this message]
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=20171102214613.10af365e@jupiter.sol.kaishome.de \
--to=hurikhan77@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 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).