NAME

fssconfig — configure file system snapshot devices

SYNOPSIS

fssconfig [-c] [-xv] fssdev fs snapstore [cluster [size]]

fssconfig -u [-v] fssdev

fssconfig -l [-v] [fssdev]

DESCRIPTION

The fssconfig command configures fss(4) file system snapshot pseudo disk devices. It will associate the file system snapshot disk fssdev with a snapshot of the file system mounted on the mount point fs. The snapshot can be mounted from the block device fssdev with mount(8).

The file system can remain in use when a snapshot is taken. As parts of the file system are overwritten, old data will be stored in the snapshot backing store snapstore, which can be either a regular file or a raw character disk device, so that the old data will remain unchanged through fssdev since the snapshot was taken.

Only a whole mounted file system, not arbitrary subdirectories, can have snapshots with fss(4); the fs parameter must specify a file system mount point.

There are two types of snapshot: persistent and non-persistent.

persistent

snapstore is a regular file on the same file system as it is a snapshot of, and the snapshot persists until snapstore is unlinked, even if the fssdev used to create it is unconfigured or the system is rebooted.

After it has been created, a persistent snapshot can be loaded again from snapstore with the same

fssconfig
      [-c] fssdev fs
      snapstore

command that was used to create it.

Unlinked but open files get removed from the snapshot. The time needed to create a persistent snapshot increases with the size of the file system and decreases with the file system block size. File systems may limit the total number of snapshots per volume.

Supported file system types:

File system	Max snapshots
ffs	20

non-persistent

snapstore is a disk device, or a regular file on a separate file system from the one it represents a snapshot of, and becomes invalid as soon as it is unconfigured.

Unlinked but open files are still present on the snapshot. The time needed to create a snapshot is independent of the size of the file system or the file system block size.

Any type of file system in NetBSD mounted from a disk device, such as ffs, ext2fs, and msdos (but not, for example, procfs, ptyfs, tmpfs, or zfs), can have non-persistent snapshots taken.

Options indicating an action to be performed:

-c

Configure the device. If successful, the block device fssdev will expose the contents of the file system mounted at fs at the time the snapshot was taken.

If snapstore is an existing persistent snapshot of fs, fssconfig will load it so that the past state of the file system represented by snapstore is exposed through fssdev. Otherwise, fssconfig will create a backing store at snapstore to take a new snapshot.

When taking a new snapshot, snapstore must either not exist or be an existing directory:

If snapstore doesn't exist, fssconfig will create a file with that name.
If snapstore is an existing directory, fssconfig will create a temporary file with an unpredictable name in that directory as the snapshot's backing store, and then immediately unlink the file, so that the storage will be released once fssdev is unconfigured.

Overwritten data will be saved in units of at least cluster bytes, or units of the file system's preferred I/O size (statvfs(5), f_iosize) if cluster is zero or unspecified. The backing store will be limited to size bytes, which defaults to the size of the file system (statvfs(5), f_blocks * f_iosize); if the backing store fills up, write operations on the file system will fail.

-l

List the snapshot devices and indicate which ones are in use. If a specific fssdev is given, then only that will be described.

-u

Unconfigure the fssdev.

If no action option is given, -c is assumed.

Other options:

-v: Be more verbose listing the snapshot devices.
-x: (-c only) Unlink snapstore after the fssdev is configured.
If snapstore is a directory for fssconfig to create a temporary file in, that file will always be unlinked, with or without -x.

FILES

/dev/rfss?: Raw character device with read access to snapshot content.
/dev/fss?: Block device for mounting a file system from a snapshot.

EXAMPLES

Take a persistent snapshot of the ffs file system /home, stored at /home/.snap/20260706.store, and mount the snapshot at /home/.snap/20260706:
```
# fssconfig fss0 /home /home/.snap/20260706.store
# mkdir /home/.snap/20260706
# mount /dev/fss0 /home/.snap/20260706
```
The snapshot will persist at /home/.snap/20260705.store and, even after unconfiguring fss0 or even rebooting, can be mounted again later:
```
# fssconfig fss0 /home /home/.snap/20260706.store
# mount /dev/fss0 /home/.snap/20260706
```
Take a snapshot of the msdos file system /boot, saving overwritten data at a temporary file in /tmp that will immediately be unlinked, and mount the snapshot at /mnt:
```
# fssconfig fss1 /boot /tmp/
# mount /dev/fss1 /mnt
```
Once fss1 is unconfigured, the backing store will be released and the snapshot cannot be recovered again.
Take a snapshot of /, saving overwritten data on the ld0e disk partition in units of 8192 bytes:
```
# fssconfig fss2 / /dev/rld0e 8192
```
Note that you must pass the raw character device /dev/rld0e, not the block device /dev/ld0e.

Once fss2 is unconfigured, the content of ld0e will become useless garbage.

List configured fss(4) devices:

# fssconfig -l -v
fss0: /, taken 2026-06-30 03:20:43, file system internal
fss1: /boot, taken 2026-07-06 16:42:14, 1280 cluster of 64K, 64K backup
fss2: not in use
fss3: not in use

Unmount /mnt and unconfigure the snapshot fss1 when done with it:
```
# umount /mnt
# fssconfig -u fss1
```
Take a snapshot of the ffs file system at / and dump it so it can be restored later with restore(8) — with the -X option, dump(8) will internally manage an fss(4) instance to take the snapshot and read the file system (so there is no need to use fssconfig directly):
```
# dump -X -0 -f /backups/root.20260706.dump /
```
For file system types other than ffs such as msdosfs or ext2fs, which don't support persistent snapshots, a place for a backing store must be given explicitly with the -x option to dump(8), which again will internally manage an fss(4) instance:
```
# dump -x /var/tmp/ -0 -f /backups/boot.20260706.dump /boot
```

HISTORY

The fssconfig command appeared in NetBSD 2.0.