On 2018/9/15 上午5:05, James A. Robinson wrote:
> The mail archive seems to indicate this list is appropriate
> for not only the technical coding issues, but also for user
> questions, so I wanted to pose a question here. If I'm
> wrong about that, I apologize in advance.
>
> The page
>
> https://btrfs.wiki.kernel.org/index.php/Incremental_Backup
>
> talks about the basic snapshot capabilities of btrfs and led
> me to look up what, if any, limits might apply. I find some
> threads from a few years ago that talk about limiting the
> number of snapshots for a volume to 100.
This is mostly related to send and quota, and maybe for
snapshot/subvolume removal.
(Any personally I would recommend only 20 snapshots)
Both of them needs to do backref walk in their core functionality.
Increased number of reference introduced by snapshots could bring a huge
impact to quota especially.
We have some plan to enhance it, but for now if send/quota is important
to you, it's highly recommend to limit number of snapshots to a
reasonable number.
>
> The reason I'm curious is I wanted to try and use the
> snapshot capability as a way of keeping a 'history' of a
> backup volume I maintain. The backup doesn't change a
> lot overtime, but small changes are made to files within
> it daily.
Then normally it could lead to some dilemma.
Currently the mostly common way to know how much exclusively used space
one snapshot uses is btrfs quota (qgroup).
But a lot of snapshots bring tons of performance impact, sometimes even
unacceptable.
If one don't need to account how much space a snapshot really take, it
won't be a problem though.
Despite above things, I'd like to point out that, snapshot is not backup
(which I believe everyone should have already known).
And further more for btrfs specifically, since file trees (snapshots and
subvolumes) still share the same chunk/extent/csum trees, if one of such
essential trees gets corrupted (especially for extent tree), you may not
be able to mount the fs (at least unable to do RW mount).
So it's still pretty important to take real backup.
Thanks,
Qu
>
> The Plan 9 OS has a nice archival filesystem that lets you
> easily maintain snapshots, and has various tools that make
> it simple to keep a /snapshot//mmdd snapshot going back
> for the life of the filesystem.
>
> I wanted to try and replicate the basic functionality of
> that history using a non-plan-9 filesystem. At first I
> tried rsnapshot but I find its technique of rotating and
> deleting backups is thrashing the disks to the point that it
> can't keep up with the rotations (the cp -al is fast, but
> the periodic rm -rf of older snapshots kills the disk).
>
> With btrfs I was thinking perhaps I could more efficiently
> maintain the archive of changes over time using a snapshot.
> If this is an awful thought and I should just go away,
> please let me know.
>
> If the limit is 100 or less I'd need use a more complicated
> rotation scheme. For example with a layout like the
> following:
>
> min/
> hour/
> day/
> month/
> year/
>
> The idea being each bucket, min, hour, day, month, would
> be capped and older snapshots would be removed and replaced
> with newer ones over time.
>
> so with a 15-minute snapshot cycle I'd end up with
>
> min/[00,15,30,45]
> hour/[00-23]
> day/[01-31]
> month/[01-12]
> year/[2018,2019,...]
>
> (72+ snapshots with room for a few years worth of yearly's).
>
> But if things have changed with btrfs over the past few
> years and number of snapshots scales much higher, I would
> use the easier scheme:
>
> /min/[00,15,30,45]
> /hourly/[00-23]
> /daily//
>
> with 365 snapshots added per additional year.
>
signature.asc
Description: OpenPGP digital signature
