Date: Fri, 29 Mar 2024 13:08:17 +0000 From: Sad Clouds <cryintothebluesky@gmail.com> Cc: freebsd-questions@FreeBSD.org Subject: Re: UFS snapshots and dump/restore Message-ID: <20240329130817.8bcf89e92dad709c46709e2f@gmail.com> In-Reply-To: <20240329121541.9b0163bef978b5e5fcfd54a7@gmail.com> References: <20240329121541.9b0163bef978b5e5fcfd54a7@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 29 Mar 2024 12:15:41 +0000
Sad Clouds <cryintothebluesky@gmail.com> wrote:
> Despite the nodump flag, /data/.snap/latest is still dumped and
> restored. This causes /data/.snap/latest to be reset to 0 bytes after
> running restore and the snapshot is lost. Any idea why such behaviour?
I think I know what's going on - inside the snapshot there is an empty
file with the same snapshot name. This is created before nodump is set.
To make dump/restore work without corrupting the original snapshot, I
had to rename the snapshot after creation.
Create snapshot and rename it:
# snapshot="/data/.snap/latest"
# mksnap_ffs ${snapshot}.tmp && chflags nodump ${snapshot}.tmp
# mv ${snapshot}.tmp ${snapshot}
Restore snapshot with dump then delete empty snapshot file:
# snapshot="/data/.snap/latest"
# cd $(dirname ${snapshot})/../ && dump -0 -a -h 0 -C 16 -b 64 -f - ${snapshot} | restore -xuvf -
# rm -f ${snapshot}.tmp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20240329130817.8bcf89e92dad709c46709e2f>