From: Wol <antlists@youngman.org.uk>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Re: Suggestions for backup scheme?
Date: Sat, 3 Feb 2024 17:05:25 +0000 [thread overview]
Message-ID: <d3bd02a9-eb6a-49c3-abbd-7c3115ff62ed@youngman.org.uk> (raw)
In-Reply-To: <uplo22$i1e$1@ciao.gmane.io>
On 03/02/2024 16:02, Grant Edwards wrote:
> rsnapshot is an application that uses rsync to do
> hourly/daily/weekly/monthly (user-configurable) backups of selected
> directory trees. It's done using rsync to create snapshots. They are
> in-effect "incremental" backups, because the snapshots themselves are
> effectively "copy-on-write" via clever use of hard-links by rsync. A
> year's worth of backups for me is 7 daily + 4 weekly + 12 monthly
> snapshots for a total of 23 snapshots. If nothing has changed during
> the year, those 23 snapshots take up the same amount of space as a
> single snapshot.
So as I understand it, it looks like you first do a "cp with hardlinks"
creating a complete new directory structure, but all the files are
hardlinks so you're not using THAT MUCH space for your new image?
Then rsync copies and replaces any files that have been modified?
So each snapshot is using the space required by the directory structure,
plus the space required by any changed files.
>
> My understanding of ZFS is that it has built-in snapshot functionality
> that provides something similar to what is done by rsync by its use of
> hard-links. In my current setup, there's an application called
> rsnapshot that manages/controls the snapshots by invoking rsync in
> various ways. My question was about the existence of a similar
> application that can be used with ZFS's built-in snapshot support to
> provide a similar backup scheme.
ZFS is a "copy on write" filesystem, I believe. So any changed blocks
are rewritten to new blocks, the live snapshot is updated, and if the
original block is required by older snapshots it is retained, else it is
freed. And then you can push a snapshot to another disk. I think ZFS
also has "dedupe on write", so if you're regularly pushing snapshots
you're not wasting space with duplicate data.
And that is why I like "ext over lvm copying with rsync" as my strategy
(not that I actually do it). You have lvm on your backup disk. When you
do a backup you do "rsync with overwrite in place", which means rsync
only writes blocks which have changed. You then take an lvm snapshot
which uses almost no space whatsoever.
So to compare "lvm plus overwrite in place" to "rsnapshot", my strategy
uses the space for an lvm header and a copy of all blocks that have changed.
Your strategy takes a copy of the entire directory structure, plus a
complete copy of every file that has changed. That's a LOT more.
If my hard disk changes by lets say 0.1% a day, and I take daily
snapshots, that's three years before I need to start deleting backups
assuming I'm actually using half my disk (and with terabyte disks, both
the amount of change, and the amount of disk used, is likely to be a lot
less than those figures).
Cheers,
Wol
next prev parent reply other threads:[~2024-02-03 17:05 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-30 18:15 [gentoo-user] Suggestions for backup scheme? Grant Edwards
2024-01-30 18:47 ` Thelma
2024-01-30 19:29 ` [gentoo-user] " Grant Edwards
2024-01-30 18:54 ` [gentoo-user] " Michael
2024-01-30 19:32 ` [gentoo-user] " Grant Edwards
2024-01-30 19:19 ` [gentoo-user] " Rich Freeman
2024-01-30 19:43 ` [gentoo-user] " Grant Edwards
2024-01-30 20:08 ` [gentoo-user] " Wol
2024-01-30 20:15 ` Rich Freeman
2024-01-30 20:38 ` [gentoo-user] " Grant Edwards
2024-01-31 8:14 ` gentoo-user
2024-01-31 11:45 ` John Covici
2024-01-31 13:01 ` Rich Freeman
2024-01-31 15:50 ` Grant Edwards
2024-01-31 17:40 ` Thelma
2024-01-31 17:56 ` Rich Freeman
2024-01-31 18:42 ` Wols Lists
2024-01-31 21:30 ` Rich Freeman
2024-02-01 10:16 ` Michael
2024-02-05 12:55 ` J. Roeleveld
2024-02-05 13:35 ` Rich Freeman
2024-02-06 13:12 ` J. Roeleveld
2024-02-06 20:27 ` Wols Lists
2024-02-07 11:11 ` J. Roeleveld
2024-02-07 21:59 ` Wols Lists
2024-02-08 6:32 ` J. Roeleveld
2024-02-08 17:36 ` Wols Lists
2024-02-09 12:53 ` J. Roeleveld
2024-02-06 15:38 ` Grant Edwards
2024-02-06 16:13 ` J. Roeleveld
2024-02-06 17:22 ` Grant Edwards
2024-02-07 11:21 ` J. Roeleveld
2024-01-31 18:00 ` Grant Edwards
2024-02-02 23:39 ` Grant Edwards
2024-02-02 23:58 ` Mark Knecht
2024-02-03 16:02 ` Grant Edwards
2024-02-03 17:05 ` Wol [this message]
2024-02-04 6:24 ` Grant Edwards
2024-02-04 9:59 ` Wols Lists
2024-02-04 15:48 ` Grant Edwards
2024-02-05 8:28 ` Wols Lists
2024-02-06 15:35 ` Grant Edwards
2024-02-06 16:19 ` J. Roeleveld
2024-02-06 17:29 ` Grant Edwards
2024-02-07 11:04 ` J. Roeleveld
2024-02-06 23:17 ` Wols Lists
2024-02-07 11:07 ` J. Roeleveld
2024-02-07 21:50 ` Wols Lists
2024-02-08 6:38 ` J. Roeleveld
2024-02-08 17:44 ` Wols Lists
2024-02-09 12:57 ` J. Roeleveld
2024-02-09 15:48 ` Wols Lists
2024-02-09 17:11 ` Peter Humphrey
2024-02-06 20:49 ` Wols Lists
2024-02-03 13:02 ` Michael
2024-02-03 16:15 ` Grant Edwards
2024-02-03 17:32 ` Rich Freeman
2024-02-03 18:10 ` Michael
2024-02-05 12:48 ` J. Roeleveld
2024-01-31 15:38 ` Grant Edwards
2024-02-04 10:54 ` [gentoo-user] " Paul Ezvan
2024-02-07 22:36 ` Frank Steinmetzger
2024-02-08 5:26 ` William Kenworthy
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=d3bd02a9-eb6a-49c3-abbd-7c3115ff62ed@youngman.org.uk \
--to=antlists@youngman.org.uk \
--cc=gentoo-user@lists.gentoo.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