Backing up files and folders

Go to the contents

Besides disks, volumes and VMs, bkp_agent also backs up files and folders. Instead of a source (source=) the profile names one or more paths (path=). The files go through the same store and the same chunker as block data: what the store already has is not stored again, even if it comes from a disk or VM backup. Like every run, a file run is complete on its own. Single files, whole folders or everything come back, to the original place, into another folder or as a ZIP archive.

A profile backs up either devices (source=) or files (path=), not both. License and points are the same as for every other backup of the agent.

9.1 A file profile#

For a first try the command line is enough:

bkp_agent --path /srv/daten --exclude 'cache/' --out /backup --name daten

Output:

[bkp_agent] INFO  backing up /srv/daten into /backup/default.cbs: id hash blake3
[bkp_agent] WARN  / is read without a snapshot (it is not on an LVM logical volume): files that change
                  during the backup may not match each other
[bkp_agent] INFO  5 file(s) and 2 folder(s) backed up (650011 bytes): 5 new, 0 changed, 0 unchanged, 0 deleted
[bkp_agent] INFO  done: full run 20261106T085724Z-c1d00c34-... in /backup/default.cbs: 650011 bytes in files;
                  chunks 5, new 5 (0.0% deduplicated); 652982 bytes sent, 652982 newly stored

Every further backup is the same command. The agent then reads only files whose size, times or inode have changed; it takes over all others from the run before, whole unchanged folders at once. --type full reads everything again (and starts a new store generation). After a small change the summary looks like this:

Output:

[bkp_agent] INFO  5 file(s) and 2 folder(s) backed up (480028 bytes): 1 new, 1 changed, 3 unchanged, 1 deleted
[bkp_agent] INFO  done: incremental run 20261106T085730Z-beafba22-... in /backup/default.cbs: 480028 bytes in files;
                  chunks 2, new 2 (0.0% deduplicated); 32268 bytes sent, 32268 newly stored

In the long run the backup belongs in a profile of the configuration file (packaging/bkp_agent.cfg.example contains the same example). Destinations are, as with every backup, out=, target= or sinks (Chapter 4):

/etc/bkp/bkp_agent.cfg

[fs1-files]
path=/etc
path=/srv/data
path=/home
exclude=*.tmp
exclude=/srv/data/scratch/
sinks=files-local

[sink:files-local]
type=out
path=/backup

After that bkp_agent --name fs1-files is enough. On Windows the paths carry the drive, for example path=C:\Users and path=D:\Data. The keys of a file profile:

Paths must be complete and must not appear twice. A device (/dev/…) belongs in a profile with source=; a network path (\\server\share) is refused: the files of a share are backed up on the machine that has them. If a path is inside another chosen one, it is part of it anyway. If a path is missing at run time, the agent backs up the others, names the missing one in the report and reports the run as partly successful (partial).

9.1.1 What is backed up along#

• Linux: content, permissions (mode), owner and group, times, extended attributes (xattrs) including POSIX ACLs, symbolic links (as a link, never followed), hard links (the data once) and device files, pipes and sockets (as a name only).
• Windows: content, attributes, times, the security descriptor (owner and NTFS permissions; the audit list SACL only if the account has the right to it), alternate data streams and reparse points (as a link, not entered). Files that are only in the cloud (OneDrive “Online-only”) are not downloaded and not backed up; the report names them. Long paths over 260 characters are no problem.

9.1.2 Snapshots#

So that the files match each other, the agent reads from a snapshot where possible:

• Windows: always a VSS shadow copy, one set across all drives involved (copy backup; the backup history of other programs stays untouched). If the shadow copy fails, the run fails with the next step (for example: check the service “Volume Shadow Copy”).
• Linux with LVM: if the paths are on ext2/3/4 or XFS in a logical volume, the agent takes one snapshot per volume (space as with --snapshot-size), mounts it read-only below /run/cybackup/fs and reads from there. The original paths are stored.
• Linux without LVM: the agent reads the files as they are at the moment and says so once in the report (warning above). If a file changes while it reads it, it reads it again up to twice; if it stays restless, it stores the last state and notes “changed during the backup”. The run stays successful, with a note.

--snapshot off (profile snapshot=off) reads without a snapshot even under LVM; --snapshot on makes the run fail if no snapshot is possible.

If a file backup is held (bkp_sched hold, time window, console), its snapshots are kept: on Linux the LVM snapshots (name <volume>_bkpf<job>, tags bkp_agent and bkp_job_<job>), on Windows the shadow copies as persistent copies (not with --vss-persistent off). The continuing run reads from the same snapshots, without hooks: the backup shows all files as they were at the first start, even if they were changed during the hold. If a snapshot is gone in the meantime (restart on Windows without a persistent copy, overflowed LVM snapshot, removed by hand), the run takes new ones and says so in the log; a started large file is then read from the beginning. When the backup is done, stopped (bkp_sched stop) or after --resume-max-age, the snapshots disappear.

9.1.3 Change journal on Windows#

On NTFS drives the agent remembers the position of the change journal (USN journal). At the next run it reads from it which folders have changed and searches only those; it takes over all others unchanged. With large drives and few changes this saves a lot of time. It searches all folders instead if the journal was created anew or the remembered position has already dropped out, the drive is not NTFS, the rights are missing or --type full is set. The reason is in the report (“scan”).

9.1.4 Report#

For file runs the agent's result file (--result-file) has an object files: files, folders, bytes, read, new, changed, unchanged, deleted, changed during the backup, errors, journal or full scan, and the paths without a snapshot. Errors with single files (for example “access denied”) make the run partial; a file that disappeared between scanning and reading is only a note. bkp_sched shows these numbers in its mail (lines “Files”, “Changes”, “Scan”, “Snapshot”, “Note”, “Missing”), the management console in the run list and in the log window.

9.2 Exclusions#

exclude= (repeatable) leaves out files and folders. A folder left out is skipped with everything below it. The notation:

On Windows \ counts like /, and upper and lower case do not matter. A chosen path= is never left out, even if a pattern matches.

With default-excludes=yes (default) these paths are dropped as well:

bkp_agent --help shows the list of the system concerned.

9.3 Restoring files#

bkp_restore --files works on a file run. The stores are chosen as with every restore: locally with --store, straight from the server with --server or through the sinks of a profile (Chapter 7). The run is chosen with --name (the newest), --name … --at <time> or --run <run>; --list shows file runs with their kind and the number of files:

bkp_restore --store /backup/default.cbs --list

shortened: without the columns computer, data, sent, new and retention

RUN                          CREATED           NAME                      TYPE             SOURCE  STATUS
20261106T085724Z-c1d00c34-…  2026-11-06 09:57  daten (files, 5 files)    Full          634.8 KiB  ok
20261106T085730Z-beafba22-…  2026-11-06 09:57  daten (files, 5 files)    Incremental   468.8 KiB  ok
20261106T085731Z-f2260dad-…  2026-11-06 09:57  daten (files, 5 files)    Incremental   468.8 KiB  ok

9.3.1 A typical case: getting back a deleted file#

On the machine where the file went missing, three steps are enough. bkp_restore reads bkp_agent.cfg (with sinks.cfg next to it) and finds the stores and keys of the sinks by itself; --store or --server are not needed. In the example the profile daten backs up the folder /srv/daten onto two USB disks (usb1, usb2); usb2 is unplugged at the moment.

1. Which backups are there? bkp_restore --list without further details shows all backups of all profiles, each once, with the sinks it is on. A sink that cannot be reached at the moment is listed calmly below the table, with the next step; the other backups appear all the same. If a file backup is among them, the footer gives the search command.

bkp_restore --list

shortened: without the columns computer, source, data, sent, new and retention

RUN                          CREATED           NAME                      TYPE         STATUS  SINKS
20261106T163945Z-4c5cbe47-…  2026-11-06 17:39  daten (files, 4 files)    Full         ok      usb1
20261106T164051Z-9fe20cc8-…  2026-11-06 17:40  daten (files, 4 files)    Incremental  ok      usb1
20261106T164152Z-619e4739-…  2026-11-06 17:41  daten (files, 4 files)    Incremental  ok      usb1
every run restores on its own (full and incremental alike); SINKS = where the backup is
to find a file: bkp_restore --name <backup> --files find "<pattern>"
usb2: not reachable right now; connect the drive or check the folder /media/usb2, then call again

Starting from the scheduler's job, bkp_sched show <job> gives profile, sinks and the matching command (Chapter 13, “A job in detail”); which sinks there are and whether they can be reached is shown by bkp_restore --sinks:

bkp_restore --sinks

Output:

NAME  KIND    LOCATION     REACHABLE             PROFILES
usb1  folder  /media/usb1  yes                   daten
usb2  folder  /media/usb2  no (folder missing)   daten
PROFILES = the backups (--name) writing into the sink; all backups: bkp_restore --list

2. Find the file and look at its versions. --files find searches all runs of the backup; * before and after the part of the name finds the file even if you no longer know the exact name. --files versions then shows every version with the last run it appeared in.

bkp_restore --name daten --files find "*Angebot*"
bkp_restore --name daten --files versions /srv/daten/projekte/Angebot-Mueller.docx

shortened: without time stamps, message numbers and the repeated note about usb2

[bkp_restore] INFO  sink usb2 is not reachable right now (the folder /media/usb2 is missing); going on without it. To
                    include it, connect the drive and call again
[bkp_restore] INFO  2 match(es) in 3 run(s) of the backup daten
TYPE  SIZE  MODIFIED          FIRST SEEN        LAST SEEN         RUNS  PATH
file  19 B  2026-11-06 17:39  2026-11-06 17:39  2026-11-06 17:39     1  /srv/daten/projekte/Angebot-Mueller.docx
file  31 B  2026-11-06 17:40  2026-11-06 17:40  2026-11-06 17:40     1  /srv/daten/projekte/Angebot-Mueller.docx

[bkp_restore] INFO  2 version(s) in 3 run(s); restore one with --run <last run> --files restore <path>
                    (--as-version keeps the current file)
Versions of /srv/daten/projekte/Angebot-Mueller.docx:
#  TYPE  SIZE  MODIFIED          FIRST SEEN        LAST SEEN         RUNS  LAST RUN
1  file  19 B  2026-11-06 17:39  2026-11-06 17:39  2026-11-06 17:39     1  20261106T163945Z-4c5cbe47-…
2  file  31 B  2026-11-06 17:40  2026-11-06 17:40  2026-11-06 17:40     1  20261106T164051Z-9fe20cc8-…

If --files find finds nothing (exit code 4), it gives the reasons that apply below, each as a note with the next step:

• The pattern contains neither * nor ? nor / and therefore matches only exactly this name; for a part of a name, for example "*offer*".
• The path searched for is outside the backed-up folders (the message names them) or is left out of the backup by exclude= or the default exclusions (the message names the rule, also for paths below an excluded folder).
• A run skipped the path with a warning, for example because the file could not be read: run, time and reason.
• Always: which runs were searched (number, first and last, local time), that older states are gone after their retention and files after the last run are not backed up yet; with --since/--until also that nothing outside was searched.
• Runs that could not be read, with the next step.

The same reasons (without the first) are given by --files versions, restore and ls when the path is missing in the run. With --json <file> they are in the field hints for programs (exact_name, outside_paths, excluded, warning, span, unread).

3. Get it back. With --run and the last run of the version wanted, to the original place (--original), into another folder (--to) or next to the current file (--as-version); without --run, --name takes the newest run, --at <time> the newest up to this point in time:

bkp_restore --name daten --run 20261106T164051Z-9fe20cc8-… --files restore /srv/daten/projekte/Angebot-Mueller.docx --original

Output:

[bkp_restore] INFO  restored: 1 file(s) (31 B), 0 folder(s), 0 link(s) and other entries;
                    0 skipped because they already exist (see --overwrite)

Many files at once are most easily looked through as a folder (--files mount, section “A run as a folder”). An unknown --name does not lead nowhere: the message names the profiles from bkp_agent.cfg (at most 20) and bkp_restore --list.

9.3.2 Looking and getting back#

bkp_restore --store /backup/default.cbs --name daten --files ls /srv/daten/projekte
bkp_restore --store /backup/default.cbs --name daten --files restore /srv/daten/projekte --to /srv/zurueck
bkp_restore --store /backup/default.cbs --name daten --files restore /srv/daten/projekte --original --overwrite older

Output:

TYPE          SIZE  MODIFIED                  NAME
file          18 B  2026-11-06T09:57:31+01:00  angebot.txt
file     195.3 KiB  2026-11-06T09:54:44+01:00  bericht1.docx
file     195.3 KiB  2026-11-06T09:54:44+01:00  bericht2.docx
file      29.3 KiB  2026-11-06T09:57:30+01:00  protokoll.pdf
[bkp_restore] INFO  restored: 4 file(s) (419.9 KiB), 1 folder(s), 0 link(s) and other entries;
                    0 skipped because they already exist (see --overwrite)

• --files ls [<path>] shows a folder of the run (without a path the top level). Paths appear as they were backed up: /etc/ssh on Linux, C:\Users\anna on Windows (input also as C:/Users/anna). find, versions, ls and diff show Windows paths with \, --json keeps /.
• --files restore <path>… gets files and folders back, a folder with everything below it, <folder>/* only its contents. With --to <folder> every chosen entry lands in this folder under its name (/srv/daten/projekte becomes /srv/zurueck/projekte); with --original in its original place, only on a system of the same kind.
• --overwrite never|older|always governs existing files: never (default) leaves them alone and counts them as skipped, older replaces them if they are older than the backed-up one, always always.
• --as-version puts a single file next to the current one, as angebot (as of 2026-11-06 09-57).txt (time of the run, local time); the current one stays untouched.
• --paths-from <file> takes further paths from a file (one per line, up to 100000), --json <file> writes the result for programs (status ok, partial or error, counters, list of errors).

Owner, permissions, extended attributes, links and times come back too (owner and device files only as root; on Windows security descriptor, attributes and alternate data streams). Every file is written under a temporary name and renamed only when finished. Names from the store never leave the destination folder, and links in the destination are not followed. If a single entry fails, bkp_restore names it, carries on with the rest and ends with exit code 3.

Files are restored on another machine by calling bkp_restore there, where the store can be reached: locally, through a sink of the profile or straight from the backup server; with an encrypted store with --decrypt-key file:<path>.

9.3.3 Searching, versions, changes#

bkp_restore --store /backup/default.cbs --name daten --files find '*.txt'
bkp_restore --store /backup/default.cbs --name daten --files versions /srv/daten/projekte/angebot.txt
bkp_restore --store /backup/default.cbs --name daten --run 20261106T085730Z-beafba22-… --files diff

Output:

[bkp_restore] INFO  4 match(es) in 3 run(s) of the backup daten
TYPE  SIZE  MODIFIED          FIRST SEEN        LAST SEEN         RUNS  PATH
link        2026-11-06 09:54  2026-11-06 09:57  2026-11-06 09:57     3  /srv/daten/link.txt
file  11 B  2026-11-06 09:54  2026-11-06 09:57  2026-11-06 09:57     1  /srv/daten/projekte/angebot.txt
file  28 B  2026-11-06 09:57  2026-11-06 09:57  2026-11-06 09:57     1  /srv/daten/projekte/angebot.txt
file  18 B  2026-11-06 09:57  2026-11-06 09:57  2026-11-06 09:57     1  /srv/daten/projekte/angebot.txt

Versions of /srv/daten/projekte/angebot.txt:
  #  TYPE  SIZE  MODIFIED          FIRST SEEN        LAST SEEN         RUNS  LAST RUN
  1  file  11 B  2026-11-06 09:54  2026-11-06 09:57  2026-11-06 09:57     1  20261106T085724Z-c1d00c34-…
  2  file  28 B  2026-11-06 09:57  2026-11-06 09:57  2026-11-06 09:57     1  20261106T085730Z-beafba22-…
  3  file  18 B  2026-11-06 09:57  2026-11-06 09:57  2026-11-06 09:57     1  20261106T085731Z-f2260dad-…

[bkp_restore] INFO  1 new, 1 changed, 1 deleted (only content and links count, not times or permissions)
~ /srv/daten/projekte/angebot.txt
- /srv/daten/projekte/bericht3.docx
+ /srv/daten/projekte/protokoll.pdf

• --files find <pattern> searches all runs of the backup (* any characters, ? one, neither across /). A pattern with / matches whole paths (/home/*/report*), otherwise the name; on Windows regardless of upper and lower case. Every version found appears once, with its first and last appearance. --since/--until narrow down the runs. Folders that stayed the same between two runs are read only once by the search; that is why it is fast even across many runs. Nothing found: exit code 4.
• --files versions <path> shows the different versions of a file across all runs. A new version comes only from changed content or a changed link target, not from times or permissions. A version is fetched back with --run <last run> --files restore <path>, with --as-version if wanted.
• --files diff [<path>] shows what is new (+), changed (~) and deleted (-) compared with the run before; --run2 <run> compares with another run.

9.3.4 As a ZIP archive#

bkp_restore --store /backup/default.cbs --name daten --files zip /srv/daten/projekte --to /srv/projekte.zip

Output:

[bkp_restore] INFO  archive written: 4 file(s) (419.9 KiB), 1 folder(s); 420.9 KiB as ZIP

The archive (ZIP64, deflate; --to - writes to standard output) contains names, contents and modification times. Owner, permissions, extended attributes, security descriptors, alternate data streams, links and device files are not in it; only --files restore brings those back.

9.4 A run as a folder#

Instead of writing files back, bkp_restore can show a whole file run as a read-only folder. It reads contents from the store only when someone opens a file; this way even large runs can be looked through at once and single files copied out with the usual tools.

bkp_restore --store /backup/default.cbs --name daten --files mount --to /mnt/daten-lauf --idle 60
ls -l /mnt/daten-lauf/srv/daten/projekte
umount /mnt/daten-lauf

Output:

Run 20261106T085731Z-f2260dad-… of the backup daten is shown read-only in /mnt/daten-lauf.
It stays until Ctrl+C or umount /mnt/daten-lauf.
/mnt/daten-lauf is unmounted.

• Linux (as root): a FUSE core of its own without an extra library. All files, links, owners, permissions and extended attributes are shown as backed up. The folder must be empty or is created and removed again afterwards. The view does not show Windows permissions and alternate data streams; those come through --files restore.
• Windows (as administrator, from Windows 10 1809 or Server 2019): through the Windows feature Projected File System (ProjFS). Files and folders are shown with sizes and times; the drives of a Windows run appear as folders without a colon (C:\mnt\C\Users\…). The view refuses writing, creating, renaming and deleting (if bkp_restore is started by hand, only a program of the same account also started as administrator can still create files there; they are removed when the view ends). If the feature is off, the management console turns it on if wanted (dism; a restart is often needed afterwards).
• --idle <minutes> ends the view after so many minutes without access (0, the default, leaves it up); --json <file> names path, run and process as long as the folder is there.

Through the scheduler (management console, button “Show as folder...”) the view is on Linux in /run/cybackup/ansicht/<job>/<run>, on Windows in Ansicht\<job>\<run> in the scheduler's queue folder (only administrators and SYSTEM). At most four views are open at the same time; after 60 minutes without access the scheduler unmounts them, and leftovers at the next start.

9.5 Files from disk and VM backups#

Single files can also be fetched from a block or VM run without restoring the whole disk, on Linux as root and on Windows as administrator. On Linux:

bkp_restore --store /backup/default.cbs --name srv1 --image-volumes
bkp_restore --store /backup/default.cbs --name srv1 --image-mount --to /mnt/srv1 --idle 60
bkp_restore --store /backup/default.cbs --name srv1 --volume disk/1 --files restore /etc/fstab --to /srv/zurueck
bkp_restore --store /backup/vm.cbs --name web1 --volume scsi0/vg0/root --files zip /var/www --to www.zip

• --image-volumes lists the volumes on the disks of the run (partitions and LVM logical volumes) with file system, size and label, and why one cannot be opened (encrypted, no file system, a volume group that cannot be opened here). --disk <slot> takes only one disk of a VM run.
• --image-mount --to <folder> mounts every volume read-only below the folder, one subfolder per volume (disk-1, scsi0-vg0-root …). Nothing is restored beforehand; the data comes from the store as it is read. Journals are not replayed, so a volume appears exactly as it was backed up. It stays until Ctrl+C, umount of all volumes or --idle.
• --volume <volume> makes --files ls, --files zip and --files restore (then with --to) work on a volume instead of a file run; the names come from --image-volumes. A search across several runs does not exist for disks.

bkp_restore can read ext2/3/4, XFS, Btrfs, NTFS, FAT and exFAT, also in LVM inside the disk. BitLocker and LUKS volumes are named as encrypted and not opened. The volume groups from the backup are opened under another name; a volume group of the machine with the same name is never touched. What an interrupted call left behind is cleaned up by the next one.

On Windows the same options apply, as administrator. The store is on this machine or is read from a backup server with --server:

bkp_restore --store D:\Backup\default.cbs --name pc1 --image-volumes
bkp_restore --store D:\Backup\default.cbs --name pc1 --image-mount --to C:\View\pc1 --idle 60
bkp_restore --store D:\Backup\default.cbs --name pc1 --volume disk/3 --files restore \Users\anna\Documents --to C:\Restored
bkp_restore --store D:\Backup\vm.cbs --name office --volume scsi0-0/2 --files zip \Data --to C:\Restored\data.zip

Output:

VOLUME  TYPE            SIZE  LABEL   NOTE
disk/1  MSR         16.0 MiB          reserved by Windows, holds no files
disk/2  ntfs       119.2 GiB  System
disk/3  ntfs       800.0 GiB  Data
disk/4  BitLocker   80.0 GiB          encrypted (BitLocker); restore the disk and open it with its key

• bkp_restore offers the disks of the run through its own read-only iSCSI target on 127.0.0.1, to which the iSCSI initiator of Windows logs on; nothing is restored beforehand and no driver is installed. The service “Microsoft iSCSI Initiator Service” (MSiSCSI) is started when needed and stopped again afterwards if it was off before. The initiator logs on – even to 127.0.0.1 – only once the computer has been connected to a network since its start (seen on Windows 11); without a network bkp_restore stops after 30 seconds with this hint. Internet access is not needed, any connected network will do.
• The disk appears read-only and without drive letters. If the backed-up disk is still attached to the machine, the copy gets new disk and partition identities so that Windows shows both at the same time; the original disk stays unchanged.
• --image-mount --to <folder> shows every readable volume as a subfolder (disk-2, scsi0-0-1 …). The folder refuses writing. The view stays until Ctrl+C, until all volume folders are unmounted (mountvol <folder> /D) or until --idle. With --viewer <SID> this user account may read the folder as well (whoami /user shows the SID); without it only programs running as administrator open it, not Explorer.
• Windows reads NTFS, ReFS, FAT and exFAT. Linux file systems and LVM are listed by --image-volumes with the note “please open it through the Target or on a Linux computer”, BitLocker and LUKS volumes as encrypted. Volumes on dynamic disks and in Storage Spaces can only be read after the disks have been restored.
• --files restore writes back time stamps, attributes, alternate data streams and permissions as for file runs and copes with long paths.
• If bkp_restore ends without taking its view down (interrupted, machine crashed), the next call or the start of the scheduler removes what is left.

The management console does this without a command line: for disk and VM jobs “Restore files” offers the choice Volume, volumes that cannot be read are greyed and name the reason; “Show as folder…” shows all readable volumes of a run as folders (Chapter 14, “Restoring files”).

9.6 Ransomware warning#

If malware encrypts the files of a machine, the next backup looks unusual: almost everything changed, many new files with strange extensions. The agent therefore compares every file run with the runs before it. A run is conspicuous if

• the share of new, changed and deleted files is above ransom-ratio (default 30 %) and at the same time ransom-factor times (default 5) the usual (median of the last 10 runs; only from 3 runs before and from 20 files touched), or
• more than 50 new files carry extensions used by extortion software: .locky, .crypt, .crypted, .cerber, .wncry, .wnry, .wcry, .zepto, .odin, .encrypted, .locked, .ryk, .conti, .lockbit, .djvu, .crypz, .cryp1, .ecc, .ezz, .exx, .aaa, .micro, .enc (pruef-virus uses the same list).

A conspicuous run is stored all the same, with a warning and the reasons in the run and in the report. bkp_sched reports it as “conspicuous” by mail, the management console marks it in the run list and in the window “Restore files”, and a backup server sends customer and operator the mail auffaellig: “Unusually many files were changed – possible encryption attack. Older states are kept.”

Above all it protects the older states: for ransom-hold-days days (default 30) no retention (agent, bkp_maintenance prune, target scheduler) deletes a run of the same backup that lies before the conspicuous one. If it was a false alarm, for example after an intended conversion of many files, an administrator lifts the protection; the run keeps a note of it:

bkp_restore --store /backup/default.cbs --run 20261106T085731Z-f2260dad-… --clear-anomaly

With ransom-check=no the check is off for a profile.

9.7 Checks on file runs#

The check chain of the target scheduler (Chapter 11) treats file runs specially: pruef-restore restores nothing but remembers run and key, pruef-mount shows the run read-only as a folder (in <mount-point>/<nn>-<backup>/files/whole), and pruef-count and pruef-virus read it there like a mounted file system. pruef-fsck and pruef-vm-start skip file runs. For a file run, bkp_dump --run <run> shows the root and the top level, --path <folder> a folder.