NAME

fssconfig — configure file system snapshot devices

SYNOPSIS

fssconfig [-cxv] fss_dev fs snapstore [cluster [size]]

fssconfig -u [-v] fss_dev

fssconfig -l [-v] [fss_dev]

DESCRIPTION

The fssconfig command configures fss(4) file system snapshot pseudo disk devices. It will associate the file system snapshot disk fss_dev with a snapshot of the file system mounted on fs, allowing fss_dev to be accessed as though it were a disk.

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 fss_dev since the snapshot was taken.

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 fss_dev 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] fss_dev
      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, fss_dev will expose the contents of fs at the time the snapshot was taken.

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

When taking a snapshot, snapstore must either not exist or be an existing directory. If it doesn't exist, fssconfig will create it. if it is an existing directory, fssconfig will create a temporary file with an unpredictable name in it as the snapshot backing store, and then immediately unlink the backing store, so the storage will be released once fss_dev 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 fss_dev is given, then only that will be described.

-u

Unconfigure the fss_dev.

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 fss_dev is configured.
If snapstore is a directory for fssconfig to create a temporary file in, that file will be unlinked anyway, 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:
```
# dump -0 -f /backups/root.20260706.dump -X /
```
For file system types other than ffs, 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 -0 -f /backups/boot.20260706.dump -x /var/tmp/ /boot
```

HISTORY

The fssconfig command appeared in NetBSD 2.0.