From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Snapper & apt-btrfs-snapshot on Ubuntu
Date: Wed, 2 Nov 2016 06:03:43 +0000 (UTC) [thread overview]
Message-ID: <pan$af500$48f5b197$b20e4aa3$ec6e2ea2@cox.net> (raw)
In-Reply-To: CAN5=xXnZmaqApRds3w=AKLAvfk=+dEPNazEb+Tzym_=2OdnfzA@mail.gmail.com
Ahmed Badr posted on Wed, 02 Nov 2016 02:00:55 +0200 as excerpted:
> Btrfs newbie here trying to figure out how to use it properly on Ubuntu
> 16.04 server.
>
> I have root formated using Btrfs, and installed Snapper [...]
I see Hans answered your direct question so I'll skip that, but one
additional hint, in case you hadn't seen it yet and your snapshot
management helpers aren't setup to take care of this automatically
(possibly because you're using two of them)...
Btrfs tends to have scaling issues if you let the number of snapshots get
too high. Try to keep it under 300 snapshots per subvolume (combined
between all tools) if at all possible, and if your use-case makes it easy
enough, try to keep it under 100 snapshots per subvolume. Definitely
don't let it get into the thousands of snapshots per subvolume, or
commands such as btrfs balance and btrfs check will take MUCH longer and
use MANY TIMES more memory.
With automated snapshot management such as snapper, just make sure it's
thinning down the snapshots at a reasonable rate as well, and ultimately
deleting the oldest ones. With proper thinning, it's easily possible to
keep to around 250-ish snapshots, even starting at ever half hour or so.
With that, proper thinning probably means thinning down to perhaps every
hour to every three hours after 24 hours, then to two snapshots a day
after a couple more days and one a day after a week. Continue thinning
after that, until after say a quarter (13 weeks) you're only keeping one
a week, and after six months you're only keeping quarterly snapshots --
if you're not deleting all snapshots at six months because you switch to
alternative media backups before that.
The thing for you is that since you're using two different automated
snapshot tools, you need to make sure the combined total still stays
below that 300, and below 100 if your use-case can handle it, as it'll
definitely mean more efficient processing if you need to run a balance or
check.
Second tip, btrfs quotas can make the scaling issues much worse. If your
use-case doesn't require them, simply turn them off (or never activate
them in the first place) and avoid the management complexity they bring.
A number of people have reported problems that simply disappeared when
they turned off btrfs quotas, so being proactive and turning them off if
you don't need them, to avoid having the issues in the first place,
certainly can't hurt.
--
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
next prev parent reply other threads:[~2016-11-02 6:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-02 0:00 Snapper & apt-btrfs-snapshot on Ubuntu Ahmed Badr
2016-11-02 0:19 ` Hans van Kranenburg
2016-11-02 11:25 ` Ahmed Badr
2016-11-02 11:44 ` Austin S. Hemmelgarn
2016-11-02 6:03 ` Duncan [this message]
2016-11-02 6:31 ` Alex Powell
2016-11-02 11:18 ` Ahmed Badr
2016-11-02 11:56 ` Austin S. Hemmelgarn
2016-11-02 11:09 ` Ahmed Badr
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$af500$48f5b197$b20e4aa3$ec6e2ea2@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