> On 20. Nov 2025, at 11:12, Sad Clouds <[email protected]> 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 - [email protected]
signature.asc
Description: Message signed with OpenPGP
