> On 20. Nov 2025, at 11:12, Sad Clouds <cryintothebluesky%gmail.com@localhost> wrote:
>
> So it seems that FFS snapshots cannot be used with dump/restore to
> recover file system data from a previous snapshot. It fails with device
> busy error.
>
> I can fall back to tar instead, however am I correct in thinking that
> NetBSD dump/restore are simply not usable in this case?
>
> I've done a similar procedure on FreeBSD and it works correctly, but
> I think they may have made specific fixes to dump/restore for
> snapshots? I'm not sure.
>
>
> Access snapshot at /mnt/.snapshots/latest:
> # mount -o log NAME=NetBSD-diag /mnt
> # snapshot_root="/mnt"
> # snapshot_dir="${snapshot_root:?}/.snapshots"
> # snapshot_name="${snapshot_dir:?}/latest"
>
> Configure /dev/fss0 snapshot device:
> # fssconfig fss0 ${snapshot_root:?} ${snapshot_name:?}
>
> Restore data from /dev/fss0 to the same file system:
> # (cd ${snapshot_root:?} && dump -0 -a -h 0 -b 64 -f - /dev/fss0 | restore -xuvf -)
Suppose you need the raw fss device (/dev/rfss0) here.
> Verify tape and initialize maps
> DUMP: Date of this level 0 dump: Thu Nov 20 09:48:09 2025
> DUMP: Date of last level 0 dump: the epoch
> DUMP: Dumping /dev/fss0 (an unlisted file system) to standard output
> DUMP: Label: none
> DUMP: mapping (Pass I) [regular files]
> DUMP: mapping (Pass II) [directories]
> DUMP: estimated 400044 tape blocks.
> DUMP: worker couldn't reopen disk DUMP: Volume 1 started at: Thu Nov 20 09:48:10 2025
> DUMP: dumping (Pass III) [directories]
> DUMP: worker couldn't reopen disk DUMP: : Device busy
> : Device busy
> DUMP: The ENTIRE dump is aborted.
> End-of-tape encountered
> Checksum error 0, inode 0 file <name unknown>
> Tape is not a dump tape
--
J. Hannken-Illjes - hannken%mailbox.org@localhostAttachment:
signature.asc
Description: Message signed with OpenPGP