[Semibug] Dump on FreeBSD ZFS file system
semibug15 at post.wayne47.com
Thu Sep 23 15:00:32 EDT 2021
On Wed, Sep 22, 2021 at 10:33:56PM -0400, stux wrote:
> Long time listener, first time caller. I was following the ZFS
> discussion and I realized I had a very similar conversation the other
> day on IRC. For those who may not know ZFS provides native backup
> facilities via "zfs send". I found this article that does a good job
> outlining how it works:
> * https://xai.sh/2018/08/27/zfs-incremental-backups.html
Well... sorta. I'm really trying, hard, to be factual and not to
be religious here.
dump/restore is really reliable and compatible. zfs send not so much.
As an example:
- I run dump on many machines, some with older versions of FreeBSD.
- A custom backup script chooses when to do a level zero, then runs
a level one every other night.
- All of the output is compressed locally, then shoved over the
network to a remote machine. This machine is not a FreeBSD box.
- The script handles things like verifying that the dump is valid
(using restore on the remote box) as well as deleting copies of
backups, based on each machine's retention policy. For a lot of
reasons, we do not want old data available.
In case of accidental file deletion, an individual file or directory
can easily be extracted on the remote machine using restore, then
copied to the original target using ssh.
In case of disaster, a new machine can be deployed. Then there are
never more than 2 restores (the level 0 and the latest level 1).
AFAICT, after many, many posts and hours of work with zfs, there is
no way to come close to this functionality. If you are running multiple
versions of zfs, you generally can not extract from a different version.
Restoring a single file on a remote machine is really not supported.
When I reported these problems as bugs and claimed that zfs was
broken, I was told "done by design".
So I run UFS and use dump.
Oh, btw, zfs is a memory pig too.
More information about the Semibug