SNAPM(8)

πŸ“¦
version 0.7.0 Β· 3 versions
, in centos-stream 10, centos-stream 9, fedora 43, fedora 44

SNAPM(8) β€” MAINTENANCE COMMANDS

okay bestie, welcome to the SNAPM(8) man page, it's literally all about the Linux Snapshot Manager and it's giving main character energy. πŸ’…βœ¨

✨ NAME ✨

snapm β€” Linux Snapshot Manager πŸ’–

🌸 SYNOPSIS 🌸

bestie, here's the whole command vibe. it's a lot, but you got this. no cap. 🫢

Command Types

       snapm [global_args] snapset create|create-
       scheduled|delete|rename|revert|resize
       |split|prune|activate|deactivate|diff|diffreport |autoactivate|list|show
       |mount|umount|exec|shell
       snapm [global_args] snapshot activate|deactivate|autoactivate|list|show
       snapm [global_args] plugin list
       snapm [global_args] schedule
       create|delete|edit|enable|disable|list|show|gc

Subcommands

       snapm snapset create [-b|--bootable] [-r|--revert] [-s|--size-
       policy policy] [-a|--autoindex] [--json] name source[size_policy]...
       snapm snapset create-scheduled -c|--config schedule_name [--json]
       snapm snapset delete [name|UUID] [-n|--name name] [-u|--uuid UUID]
       snapm snapset diff [-o|--output-format format] [-P|--pretty]
       [-D|--desc mode] [-t|--ignore-timestamps] [-p|--ignore-permissions]
       [-w|--ignore-ownership] [-c|--content-only] [-C|--no-content-diff]
       [-f|--file-types] [-F|--follow-symlinks] [-m|--max-file-size size]
       [-z|--max-diff-size size] [-H|--max-hash-size size] [-i|--include-
       pattern pattern] [-x|--exclude-pattern pattern] [-s|--start-path path]
       [--stat] [-q|--quiet] [--color mode] [-M|--cache-mode cache_mode]
       [--cache-expires expire_secs] from to
       snapm snapset diffreport [--name-prefixes|--nameprefixes] [--no-
       headings|--noheadings] [-o|--options fields] [-O|--sort sort_fields]
       [--rows|--json] [--separator separator] [-t|--ignore-timestamps]
       [-p|--ignore-permissions] [-w|--ignore-ownership] [-c|--content-only]
       [-C|--no-content-diff] [-f|--file-types] [-F|--follow-symlinks]
       [-m|--max-file-size size] [-z|--max-diff-size size] [-H|--max-hash-
       size size] [-i|--include-pattern pattern] [-x|--exclude-pattern pattern]
       [-s|--start-path path] [-q|--quiet] [--color mode] [-M|--cache-
       mode cache_mode] [--cache-expires expire_secs] from to snapm snapset
       rename old_name new_name
       snapm snapset revert [name|UUID] [-n|--name name] [-u|--uuid UUID]
       snapm snapset resize [name|UUID] [-n|--name name] [-u|--uuid UUID]
       [-s|--size-policy policy] [source[size_policy]...]
       snapm snapset split name new_name source...
       snapm snapset prune name source...
       snapm snapset activate [name|UUID] [-n|--name name] [-u|--uuid UUID]
       snapm snapset deactivate [name|UUID] [-n|--name name] [-u|--uuid UUID]
       snapm snapset autoactivate --yes|--no [name|UUID] [-n|--name name]
       [-u|--uuid UUID]
       snapm snapset list [name|UUID] [-n|--name name] [-u|--uuid UUID]
       [--name-prefixes|--nameprefixes] [--no-headings|--noheadings]
       [-o|--options fields] [-O|--sort sort_fields] [--rows|--json]
       [--separator separator]
       snapm snapset show [name|UUID] [-n|--name name] [-u|--uuid UUID]
       [--members] [--json]
       snapset mount name
       snapset umount name
       snapset exec name command
       snapset shell name

       snapm snapshot activate [name|UUID] [-n|--name name] [-u|--uuid UUID]
       [-N|--snapshot-name name] [-U|--snapshot-uuid UUID]
       snapm snapshot deactivate [name|UUID] [-n|--name name] [-u|--uuid UUID]
       [-N|--snapshot-name name] [-U|--snapshot-uuid UUID]
       snapm snapshot autoactivate --yes|--no [name|UUID] [-n|--name name]
       [-u|--uuid UUID] [-N|--snapshot-name name] [-U|--snapshot-uuid UUID]
       snapm snapshot list [name|UUID] [-n|--name name] [-u|--uuid UUID]
       [-N|--snapshot-name name] [-U|--snapshot-uuid UUID] [--name-
       prefixes|--nameprefixes] [--no-headings|--noheadings]
       [-o|--options fields] [-O|--sort sort_fields] [--rows|--json]
       [--separator separator]
       snapm snapshot show [name|UUID] [-n|--name name] [-u|--uuid UUID]
       [-N|--snapshot-name name] [-U|--snapshot-uuid UUID] [--json]

       snapm plugin list [--name-prefixes|--nameprefixes] [--no-
       headings|--noheadings] [-o|--options fields] [-O|--sort sort_fields]
       [--rows|--json] [--separator separator]

       snapm schedule create -p|--policy-type policy_type [-b|--bootable]
       [-C|--calendarspec calendarspec] [-r|--revert] [-s|--size-policy policy]
       [--keep-count count] [--keep-years years] [--keep-months months]
       [--keep-weeks weeks] [--keep-days days] [--keep-yearly yearly] [--keep-
       quarterly quarterly] [--keep-monthly monthly] [--keep-weekly weekly]
       [--keep-daily daily] [--keep-hourly hourly] schedule_name
       source[size_policy]...
       snapm schedule delete schedule_name
       snapm schedule edit [-p|--policy-type policy_type] [-b|--bootable]
       [-C|--calendarspec calendarspec] [-r|--revert] [-s|--size-policy policy]
       [--keep-count count] [--keep-years years] [--keep-months months]
       [--keep-weeks weeks] [--keep-days days] [--keep-yearly yearly] [--keep-
       quarterly quarterly] [--keep-monthly monthly] [--keep-weekly weekly]
       [--keep-daily daily] [--keep-hourly hourly] schedule_name
       [source[size_policy]...]
       snapm schedule enable schedule_name [--start]
       snapm schedule disable schedule_name
       snapm schedule list [--name-prefixes|--nameprefixes] [--no-
       headings|--noheadings] [-o|--options fields] [-O|--sort sort_fields]
       [--rows|--json] [--separator separator]
       snapm schedule show schedule_name [--json]
       snapm schedule gc -c|--config schedule_name

πŸ¦‹ DESCRIPTION πŸ¦‹

so basically, snapm is a snapshot manager for Linux systems. it manages snapshots taken at a common moment in time as a snapshot set (aka a "snapset"). it's giving coordinated snapshot vibes, periodt. πŸ’–

✨ OPTIONS ✨

okay bestie, this is the big one, the options menu, the whole ✨alphabet✨ of vibes. every single flag is here, no skips, no cap 🫢

  • -a, --autoindex β€” when you're making snapshot sets, treat name as a common basename and then generate + append a brand-new non-negative index value onto it, so you get a unique instance name. this is the moment when you're creating recurring snapshot sets over the same group of sources β€” like, say, building a timeline of snapshots for recovery and revert purposes. it's giving "i make one every hour and they all need their own lil name" πŸ’…
  • -b, --bootable β€” when creating snapshot sets, automatically create a snapshot boot entry for the set. yes queen, boot it πŸ₯Ύ
  • --cache-expires expire_secs β€” set the diff cache expiry time in seconds. 0 disables expiry entirely. the default is 900 seconds (15 minutes). heads up: this one is mutually exclusive with --cache-mode β€” pick a lane, bestie 😭
  • -C, --calendarspec calendarspec β€” the calendar event expression that triggers scheduled creation of snapshot sets. peep systemd.time(7) for the expression syntax. now listen: calendar expressions with whitespace in them (for example, "Mon *-*-* 00:00:00") must be quoted in the shell with single or double quotes, or the argument gets incorrectly parsed as a schedule name or source. do not skip the quotes, i'm begging πŸ™ˆ
  • --color mode β€” (Diff) turns on colored output. valid modes are auto, never, and always. rainbows on demand 🌈
  • -c, --config schedule_name β€” the name of a configured schedule.
  • -c, --content-only β€” (Diff) only consider content changes when comparing file systems. nothing else matters, just the content ✨
  • -C, --no-content-diff β€” (Diff) don't generate content diffs for detected file modifications. noted, skipped, moving on πŸ’…
  • -d, --debug debug_flags β€” a comma-separated list of subsystem names to enable debugging output for, or 'all' to enable literally everything. the available debug classes are: manager, command, report, schedule, mounts, fsdiff, plugin. collector energy πŸ”
  • -D, --desc mode β€” (Diff) include change description in tree output. valid modes are none, short, and full.
  • -f, --file-types β€” (Diff) generate file type information using libmagic. it knows what it is πŸ¦‹
  • -F, --follow-symlinks β€” (Diff) follow symbolic links when walking file system trees. going where they lead 🧚
  • -h, --help β€” display usage information and exit. the classic.
  • -i, --include-pattern pattern β€” (Diff) file patterns to include in comparison (glob notation).
  • --json β€” produce output in JSON notation. see the JSON OUTPUT section.
  • --keep-count count β€” retain count snapshot sets when applying the COUNT garbage collection policy.
  • --keep-years years β€” retain years snapshot sets when applying the AGE garbage collection policy.
  • --keep-months months β€” retain months snapshot sets when applying the AGE garbage collection policy.
  • --keep-weeks weeks β€” retain weeks snapshot sets when applying the AGE garbage collection policy.
  • --keep-days days β€” retain days snapshot sets when applying the AGE garbage collection policy.
  • --keep-yearly yearly β€” retain yearly yearly snapshot sets when applying the TIMELINE garbage collection policy.
  • --keep-quarterly quarterly β€” retain quarterly quarterly snapshot sets when applying the TIMELINE garbage collection policy.
  • --keep-monthly monthly β€” retain monthly monthly snapshot sets when applying the TIMELINE garbage collection policy.
  • --keep-weekly weekly β€” retain weekly weekly snapshot sets when applying the TIMELINE garbage collection policy.
  • --keep-daily daily β€” retain daily daily snapshot sets when applying the TIMELINE garbage collection policy.
  • --keep-hourly hourly β€” retain hourly hourly snapshot sets when applying the TIMELINE garbage collection policy.
  • -H, --max-hash-size size β€” (Diff) maximum file size for generating content hashes (default: 1MiB).
  • -m, --max-file-size size β€” (Diff) maximum file size for comparisons (0=unlimited).
  • -M, --cache-mode cache_mode β€” specify diff caching mode (auto, never, always). the default (auto) automatically expires the diff cache after 900 seconds (15 minutes). using always disables cache expiry. to disable the use of the cache entirely, use never. and this option is mutually exclusive with --cache-expires β€” fr fr, one or the other πŸ™…
  • --members β€” include individual snapshots in the output of snapset show commands. show me everyone 🫢
  • -n, --name name β€” specify a snapshot set name to operate on.
  • --name-prefixes | --nameprefixes β€” add a 'SNAPM_' prefix plus the field name to the output. super useful with --noheadings to produce a list of field=value pairs that can be used to set environment or shell variables. chef's kiss for scripting πŸ‘‘
  • --no-headings | --noheadings β€” suppress output of report headings. no headers, just vibes.
  • -o, --options fields β€” specify which fields to display.
  • -o, --output-format format β€” (Diff) output format for diff data. valid formats are paths, full, short, json, diff, summary, and tree. this option may be specified multiple times to print different output formats for the same run. the default if --output-format is not specified is tree. the way that you can stack these... obsessed 🌸
  • -O, --sort sort_fields β€” specify which fields to sort by.
  • -s, --start-path path β€” (Diff) start traversal from the specified path. this option may be specified multiple times to traverse different subtrees in a single diff operation. multitasking queen ✨
  • --stat β€” (Diff) include diffstat output in diff and summary output.
  • -p, --ignore-permissions β€” (Diff) ignore permissions when computing diffs.
  • -p, --policy-type policy_type β€” select the garbage collection policy applied to snapshot sets created by a schedule. valid values are ALL, COUNT, AGE, and TIMELINE.
  • -P, --pretty β€” (Diff) pretty print output if supported by output format (e.g. JSON). make it cute πŸ’…
  • -q, --quiet β€” (Diff) do not output progress or status information. shhh 🀫
  • -r, --revert β€” when creating snapshot sets, automatically create a snapshot revert entry for the set.
  • --rows β€” output report columns as rows. rotate that whole situation 90 degrees πŸ”„
  • --separator separator β€” report field separator.
  • -s, --size-policy size_policy β€” specify a default size policy when creating snapshot sets.
  • -N, --snapshot-name name β€” specify a snapshot name to operate on.
  • -U, --snapshot-uuid UUID β€” specify a snapshot UUID to operate on.
  • --start β€” start the specified schedule immediately when enabling it with snapm schedule enable. no waiting, we go now πŸ”₯
  • -t, --ignore-timestamps β€” (Diff) ignore timestamps when computing diffs.
  • -u, --uuid UUID β€” specify a snapshot set UUID to operate on.
  • -v, --verbose β€” increase verbosity level. specify multiple times, or set additional debug classes with --debug, to enable more verbose messages. the more the merrier πŸ’œ
  • -V, --version β€” display the version of snapm and exit.
  • -w, --ignore-ownership β€” (Diff) ignore ownership when computing diffs.
  • -x, --exclude-pattern pattern β€” (Diff) file patterns to exclude from comparison (glob notation).
  • -z, --max-diff-size size β€” (Diff) maximum file size for generating content diffs (default: 1MiB).

πŸ”Ž Identifier arguments

okay so this is important and also lowkey so simple once you clock it πŸ‘‘

commands that accept an identifier may use either a positional name or UUID, or the explicit options -n | --name and -u | --uuid (with snapshot variants -N | --snapshot-name and -U | --snapshot-uuid).

these forms are mutually exclusive. mixing positional and explicit arguments in the same invocation is a parse error; in this case the command exits with status 2.

bestie. pick ONE way to name your thing. positional OR explicit. mixing them = parse error = exit status 2 = we do not do that here πŸ’€

✨ SNAPSHOT SETS AND SNAPSHOTS ✨

okay bestie, so snapm manages named collections of snapshots β€” snapshots that were all taken at one common point in time β€” and we call those collections snapshot sets. πŸ’– You build a snapshot set out of a list of sources (mount point paths or block device paths), and boom: you've captured the state of your system spanning across several volumes at once. main character energy fr.

Valid characters for snapshot set names are: a–z A–Z 0–9 + . -

The underscore character (_) is not permitted. Not even a little. Don't try it. 😭

Snapshot sets and snapshots are also identified by a unique UUID value.

A plugin model is used to map mount points or devices onto possible snapshot providers. A provider plugin must exist for each source path specified when creating a snapshot set. The current plugins support LVM2 copy-on-write, LVM2 thin provisioned and Stratis snapshots.

Plugins are assigned a positive integer priority value: in the case that two or more plugins are able to snapshot the same source (for example, lvm2-cow vs. lvm2-thin on the same logical volume, or file system vs. block device snapshots), the plugin with the greater priority value is selected automatically. it's giving "may the best plugin win" πŸ†

Plugins have a default static priority value assigned by the plugin author. System administrators can override this by modifying the appropriate file in /etc/snapm/plugins.d. See snapm-plugins.d(5) for further information.

The snapset subcommand allows snapshot sets to be created, deleted, enumerated, renamed, reverted, and activated or deactivated.

The snapshot subcommand provides access to information describing individual snapshots that are part of a snapshot set, for example the device path and snapshot status.

πŸ’« Snapshot set and snapshot status πŸ’«

Snapshots from different providers may exist in several possible states: Active, Inactive, Invalid, or Reverting.

Some providers allow snapshots to be in an Active or Inactive state and snapshots for some providers (for example LVM2 Copy-on-Write snapshots) have a specific size for the snapshot data store. If this space is completely consumed the snapshot becomes Invalid and can no longer be accessed. πŸ’€

When a revert is executed for a snapshot set that is currently mounted the status of the snapshot set is Reverting. If the snapshot set is in use (either the origin or snapshot volumes are mounted) the revert will take place the next time the volumes making up the snapshot set are activated and the snapshot set status will remain Reverting until the operation is complete.

The status of a snapshot set is an aggregation of the status of the individual snapshots it contains: if any snapshots are Invalid then the overall status of the snapshot set is also Invalid. If any snapshots within the set are Reverting then the snapshot set status as a whole is also Reverting. Finally, if any snapshots are Inactive then the status of the snapshot set is Inactive.

πŸŽ€ Snapshot size policies πŸŽ€

An optional size policy hint can be specified when creating a snapshot set, either as a global default or individually for each source path. The policy is used at creation time to check that sufficient space is present.

For snapshot providers that require a fixed space to be allocated for the snapshot the policy is used to determine the size of the snapshot backing store.

There are currently four types of size policy that can be used to specify the space required:

  • FIXED β€” A fixed size with optional unit suffix (MiB, GiB, TiB, etc.).
  • %FREE β€” A percentage of the free space available from 0 to 100%.
  • %USED β€” A percentage of the space currently consumed on the mount point, as reported by df. Values greater than 100% can be used to allow the existing content to be completely overwritten without running out of space. This policy can only be applied to snapshot sources that correspond to mounted file systems.
  • %SIZE β€” A percentage of the size of the origin volume from 0 to 100%.

The default size policy for mounted volumes if none is specified is 200%USED. The default size policy for unmounted block devices is 25%SIZE.


πŸ‘‘ COMMANDS πŸ‘‘

Snapshot manager commands consist of a type (snapset, snapshot, plugin, schedule), followed by a type-specific subcommand.

🌸 Snapshot Set Commands 🌸

snapm snapset create [-b|--bootable] [-r|--revert] [-s|--size-policy policy] [-a|--autoindex] [--json] name source[size_policy]...

Create a new snapshot set using the specified list of mount points and block devices. πŸ¦‹

The newly created snapshot set is displayed on the terminal on success:

# snapm snapset create backup / /home /var /opt /srv
SnapsetName:      backup
Sources:          /, /home, /var, /opt, /srv
NrSnapshots:      5
Time:             2024-12-05 17:46:12
UUID:             87c89914-51a5-5043-8513-667100213243
Status:           Inactive
Categories:       daily, hourly
Autoactivate:     no
Mounted:          no
Bootable:         no

When creating snapshot sets --bootable and --revert can optionally be used to automatically create snapshot boot and revert boot entries respectively.

A size policy can be specified on the create command line, either as a global default or individually for each source path. To specify a default policy use the --size-policy argument. To specify a per-source path size policy append the policy to the source path separated by the : character:

# snapm snapset create backup --size-policy 25%FREE /:4G /home /var
SnapsetName:      backup
Sources:          /, /home, /var
NrSnapshots:      3
Time:             2024-12-05 17:47:19
UUID:             4106d5b5-b521-504d-8822-8826594debb5
Status:           Inactive
Categories:       daily, hourly
Autoactivate:     no
Mounted:          no
Bootable:         no

Snapshot providers that do not allocate a fixed size for snapshot data will check for available space according to the policy at creation time but do not enforce a fixed size for individual snapshots: space is allocated from the available pool on an as-needed basis.

If the --autoindex argument is given the name given on the command line is treated as a basename and a new, non-negative integer index will be generated and appended to the name to construct a new, unique instance name. This can be used to group a series of snapshot sets of the same set of sources that are taken on a recurring schedule. πŸ”

# snapm snapset create hourly --autoindex /:5%SIZE /var:5%SIZE
SnapsetName:      hourly.3
Sources:          /, /var
NrSnapshots:      2
Time:             2025-03-26 14:17:18
UUID:             ae082452-7995-5316-ac65-388eadd9879c
Status:           Active
Categories:       daily, hourly
Autoactivate:     yes
Mounted:          no
Bootable:         no

snapm snapset create-scheduled -c|--config schedule_name [--json]

Create scheduled snapshot sets according to named configuration. This command is normally called by the corresponding schedule timer. It may be issued manually for testing or debugging purposes, or to create additional snapshot sets not specified by the schedule parameters.


snapm snapset delete [name|UUID] [-n|--name name] [-u|--uuid UUID]

Delete the specified snapshot set. The snapshot set to delete may be specified either by its name or UUID. (rip bozo 🫑)


snapm snapset diff [-o|--output-format format] [-P|--pretty]
[-D|--desc mode] [-t|--ignore-timestamps] [-p|--ignore-permissions]
[-w|--ignore-ownership] [-c|--content-only] [-C|--no-content-diff]
[-f|--file-types] [-F|--follow-symlinks] [-m|--max-file-size size]
[-z|--max-diff-size size] [-H|--max-hash-size size]
[-i|--include-pattern pattern] [-x|--exclude-pattern pattern]
[-s|--start-path path] [--stat] [-q|--quiet] [--color mode]
[-M|--cache-mode cache_mode] [--cache-expires expire_secs] from to

Compare two snapshot sets, or a snapshot set and the running system. πŸ‘€

Calculates the differences between the from and to targets. Targets may be specified as a snapshot set name, or the special character . to represent the currently running system (root file system).

If --start-path is not specified the comparison proceeds from the root directory of the two volumes. This can be costly in terms of both time and memory: for better performance, specify one or more start paths in order to focus the difference generation on areas of interest. A resource use warning is emitted if no start path is given (this warning can be suppressed using the --quiet argument). ⚠️

The output format is controlled by --output-format. The tree format provides a hierarchical view of changes, while diff provides standard unified diff output for modified content: see Output Formats for a full description of the available formats. Multiple output formats may be specified by repeating the --output-format argument with the required formats. The default format if no --output-format is specified is tree.

File comparisons can be tuned to ignore specific attributes (timestamps, permissions, ownership) or to filter based on file patterns and sizes.

By default the results of diff computations are stored in an on-disk cache. The default cache expiry time is 900 seconds (15 minutes). Cache behaviour can be controlled with the --cache-mode and --cache-expires options.

Output Formats

paths, full, short, json, diff, summary, tree

The --output-format option accepts the following values:

  • paths β€” A simple list of changed paths, one per line.
  • full β€” Detailed change information including file attributes (mode, user, group, size, time).
  • short β€” Abbreviated change description (path, difference type and summary).
  • json β€” Change data formatted as a JSON object.
  • diff β€” Standard unified diff output of file content changes.
  • summary β€” A brief summary of the count of different change types.
  • tree β€” (Default) A hierarchical tree view of changes, using prefixes to indicate status.

🌈 Tree Output Legend 🌈

The tree output format uses the following prefixes to indicate file status:

  • [+] Path added (green) πŸ’š
  • [-] Path removed (red) ❀️
  • [*] β€” Path modified (yellow) πŸ’›
  • [<] β€” Path moved from (cyan) 🩡
  • [>] β€” Path moved to (cyan) 🩡
  • [!] β€” Path file type changed (blue) πŸ’™

okay bestie, next up is the one that does the same detective work as diff but hands you a whole table at the end instead of a wall of text. iconic behavior honestly.

snapm snapset diffreport [--name-prefixes|--nameprefixes] [--no-headings|--noheadings]
                         [-o|--options fields] [-O|--sort sort_fields]
                         [--rows|--json] [--separator separator]
                         [-t|--ignore-timestamps] [-p|--ignore-permissions]
                         [-w|--ignore-ownership] [-c|--content-only]
                         [-C|--no-content-diff] [-f|--file-types]
                         [-F|--follow-symlinks] [-m|--max-file-size size]
                         [-z|--max-diff-size size] [-H|--max-hash-size size]
                         [-i|--include-pattern pattern] [-x|--exclude-pattern pattern]
                         [-s|--start-path path] [-q|--quiet] [--color mode]
                         [-M|--cache-mode cache_mode] [--cache-expires expire_secs]
                         from to

Compare snapshot sets and output results in a tabular report ✨

It runs the exact same comparison logic as snapm snapset diff, it just formats the output as a report using the standard reporting columns. Same brain, cuter outfit. πŸ’…

🫢 real talk: if you don't pass --start-path, the comparison starts all the way up at the root directory of the two volumes. That's lowkey expensive in both time and memory. For better performance, give it one or more start paths so it only focuses the difference generation on the areas you actually care about. And fr fr, if you give it no start path at all, it emits a resource use warning β€” you can shut that up with the --quiet argument. 😭

This command supports standard reporting arguments, including --options, --sort, --noheadings, and --json. πŸŽ€


snapm snapset rename old_name new_name

Rename an existing snapshot set. The one getting a glow-up is old_name, and its new name is new_name. It's giving rebrand era. πŸ’–


snapm snapset revert [name|UUID] [-n|--name name] [-u|--uuid UUID]

Revert an existing snapshot set β€” meaning it re-sets the content of the origin volumes back to the state they were in at the time the snapshot set was created. Time travel but make it storage. βͺ✨

You can point at the snapshot set you want reverted either by its name or its UUID.

πŸ‘€ heads up: if the origin volumes are mounted and in use, reverting gets scheduled instead β€” it'll happen the next time those volumes get activated, for example by booting into a configured revert boot entry for the snapshot set. So it's not instant, it's pending, bestie.

snapm snapset resize [name|UUID] [-n|--name name] [-u|--uuid UUID]
                     [-s|--size-policy policy] [source[size_policy]...]

Resize the members of an existing snapshot set β€” re-applying size policies to one or more of the snapshots that make up the set. Again, you can name it by name or UUID. πŸ‘‘

So here's the tea on how it works: for snapshot providers that need a fixed amount of space allocated to the snapshot, this command will physically resize the corresponding snapshot according to the given size policy (lvm2-cow). For providers that allocate space dynamically, the command just checks that the requested space is available at the time you run the resize. If the size policies you asked for can't be satisfied, you get an error. no cap. 🫠

Size policies can be set per-source using the same syntax as the snapset create command. You can set a default size policy with the --size-policy argument. And if you don't specify any source paths at all, the command applies the default size policy to each member of the snapshot set. convenient much? πŸ’…

🚨 the lvm2-cow plugin does not support shrinking snapshots, because that's just not a thing the LVM2 tools support. So don't even try it. πŸ’€

snapm snapset split name new_name source...

Split snapshots from an existing snapshot set into a new snapshot set. πŸ¦‹

So you take the snapshot set named name and split it into a new snapshot set named new_name. Every source you list from name gets moved into the new set. Sources you don't list stay right where they are, in the original set. And yes β€” trying to split all sources out of a snapshot set is an error; in that case you should use snapm snapset rename instead. read the room. πŸ™ˆ


snapm snapset prune name source...

Prune snapshots from an existing snapshot set. βœ‚οΈ

It prunes the listed sources from the snapshot set named name β€” and those snapshot sources are permanently deleted.

🚨 THIS OPERATION IS IRREVERSIBLE. There is no undo button, no take-backs, no "wait bestie I didn't mean it." Be absolutely sure before you run this. πŸ’€

And same energy as split: it's an error to prune all sources from a snapshot set β€” in that case, use snapm snapset delete instead. πŸŽ€


snapm snapset activate [name|UUID] [-n|--name name] [-u|--uuid UUID]

Attempt to activate the snapshots making up snapshot sets. If you give it no argument, it'll try to activate all snapshots of all snapshot sets present on the system. If you specify a name or UUID, then only that snapshot set gets activated. 🌈

⚠️ not all snapshot providers support optional activation for snapshot volumes. For those providers, activate and deactivate have no effect on volume availability. So don't be surprised if nothing visibly happens. 😭

snapm snapset deactivate [name|UUID] [-n|--name name] [-u|--uuid UUID]

Attempt to deactivate the snapshots making up snapshot sets. No argument? It tries to deactivate all snapshots of all snapshot sets present on the system. Name or UUID specified? Only that one snapshot set gets deactivated. πŸ’€

⚠️ same caveat as above: not all snapshot providers support optional activation for snapshot volumes, and for those providers activate and deactivate have no effect on volume availability. 🫢

snapm snapset autoactivate --yes|--no [name|UUID] [-n|--name name]
                           [-u|--uuid UUID]

Enable or disable snapshot autoactivation for snapshot sets matching your selection criteria. Some snapshot providers (lvm2-thin) support optional snapshot volume activation when activating resources β€” for example at boot time. The snapset autoactivate subcommand lets you control this behavior for snapshot sets managed by snapm. 🧚


snapm snapset list [name|UUID] [-n|--name name] [-u|--uuid UUID]
                   [--name-prefixes|--nameprefixes] [--no-headings|--noheadings]
                   [-o|--options fields] [-O|--sort sort_fields] [--rows|--json]
                   [--separator separator]

Output a tabular report of snapshot sets. πŸ“‹βœ¨

It displays a report with one snapshot set per line, containing fields that describe the properties of the configured snapshot sets.

The list of fields to display is given with -o|--options as a comma separated list of field names. Wanna know what fields exist? Run snapm snapset list -o help. πŸŽ€ And here's the little trick: if your list of fields begins with the + character, the fields you named get appended to the default field list. Otherwise your list replaces the default set of report fields. subtle but so useful.

The --rows, --noheadings, and --nameprefixes options can be used to generate output in a machine readable form, suitable for setting shell or environment variables. πŸ€–

Report output may be sorted by multiple user-defined keys using the --sort option. It expects a comma separated list of keys, with optional + and - prefixes meaning ascending and descending sort for that field respectively. so + for ascending, - for descending, got it. πŸ’…


snapm snapset show [name|UUID] [-n|--name name] [-u|--uuid UUID]
                   [--members] [--json]

Display snapshot sets matching your selection criteria on standard out. If you pass the --members option, individual snapshots get included in the output too. πŸ‘€


snapm snapset mount name

Mount the members of the specified snapshot set. The root volume gets mounted at /run/snapm/mounts/<name>. And the bind mounts for API and runtime file systems are created automatically β€” you don't gotta do a thing. πŸ’–


snapm snapset umount name

Unmount the specified snapshot set members from /run/snapm/mounts/<name>. byeee πŸ‘‹


snapm snapset exec name command

Execute the specified command inside snapshot set name. Any arguments that come after command are passed through verbatim β€” no editing, no interpreting, just straight through. πŸ”₯


snapm snapset shell name

Start an interactive shell in snapshot set name. go poke around, bestie. 🐚✨


πŸ‘‘ Snapshot Commands πŸ‘‘

(yes, individual snapshots get their own command family, we're fancy like that)

snapm snapshot activate [name|UUID] [-n|--name name] [-u|--uuid UUID]
                        [-N|--snapshot-name name] [-U|--snapshot-uuid UUID]

Attempt to activate individual snapshots matching your selection criteria. No argument given? It'll try to activate all snapshots of all snapshot sets present on the system. If a snapshot or snapshot set name or UUID is specified, then only the matching volumes get activated. 🌈

⚠️ not all snapshot providers support optional activation for snapshot volumes β€” for those providers, activate and deactivate have no effect on volume availability. 🫠

snapm snapshot deactivate [name|UUID] [-n|--name name] [-u|--uuid UUID]
                          [-N|--snapshot-name name] [-U|--snapshot-uuid UUID]

Attempt to deactivate individual snapshots matching your selection criteria. No argument? It tries to deactivate all snapshots of all snapshot sets present on the system. Snapshot or snapshot set name or UUID specified? Only the matching volumes get deactivated. πŸ’€


⚠️ Not all snapshot providers support optional activation for snapshot volumes: for these providers activate and deactivate have no effect on volume availability.

snapm snapshot autoactivate --yes|--no [name|UUID] [-n|--name name]
                            [-u|--uuid UUID] [-N|--snapshot-name name]
                            [-U|--snapshot-uuid UUID]

Enable or disable snapshot autoactivation for individual snapshots matching your selection criteria. Some snapshot providers (lvm2-thin) support optional snapshot volume activation when activating resources, e.g. at boot time. The snapshot autoactivate subcommand lets you control this behavior for individual snapshots managed by snapm. 🧚✨


snapm snapshot list [name|UUID] [-n|--name name] [-u|--uuid UUID]
                    [-N|--snapshot-name name] [-U|--snapshot-uuid UUID]
                    [--name-prefixes|--nameprefixes] [--no-headings|--noheadings]
                    [-o|--options fields] [-O|--sort sort_fields] [--rows|--json]
                    [--separator separator]

Output a tabular report of snapshots. πŸ“‹πŸ’–

It displays a report with one snapshot per line, containing fields that describe the properties of the configured snapshots. πŸŽ€

okay so like, the field list is a whole thing, let me explain πŸ’…

The list of fields to display is given with --options as a comma separated list of field names. Wanna know what fields even exist? Run 'snapm snapshot list -o help' and it'll tell you, bestie, it's giving menu. And here's the little trick: if the list of fields begins with the '+' character, the specified fields are appended to the default field list. Otherwise the given list of fields replaces the default set of report fields. Glow up or full makeover, your choice ✨

The --rows, --noheadings, and --nameprefixes options can be used to generate output in a machine readable form, suitable for setting shell or environment variables. Scripts love that, no cap 🫢

Report output may be sorted by multiple user-defined keys using the --sort option. The option expects a comma separated list of keys, with optional + and - prefixes indicating ascending and descending sort for that field respectively. So like, + is going up, - is going down, iconic behaviour honestly πŸ’…


πŸ¦‹ Snapshots, but make it show πŸ¦‹

snapm snapshot show [name|UUID] [-n|--name name] [-u|--uuid UUID] [-N|--snapshot-name name] [-U|--snapshot-uuid UUID] [--json]

Display snapshots matching selection criteria on standard out. That's it, that's the vibe, it just shows you the matching snapshots πŸ“Έ


πŸ’– Plugin Commands πŸ’–

snapm plugin list [--name-prefixes|--nameprefixes] [--no-headings|--noheadings] [-o|--options fields] [-O|--sort sort_fields] [--rows|--json] [--separator separator]

Output a tabular report of plugins. 🌸

Displays a report with one plugin per line, containing fields describing the properties of the available plugins. One plugin, one line, very demure, very mindful πŸŽ€

The list of fields to display is given with --options as a comma separated list of field names. To obtain a list of available fields run 'snapm plugin list -o help'. If the list of fields begins with the '+' character the specified fields are appended to the default field list. Otherwise the given list of fields replaces the default set of report fields. Same deal as always, you know the drill by now πŸ’…

The --rows, --noheadings, and --nameprefixes options can be used to generate output in a machine readable form, suitable for setting shell or environment variables. Scripts eat this up fr fr 🫢

Report output may be sorted by multiple user-defined keys using the --sort option. The option expects a comma separated list of keys, with optional + and - prefixes indicating ascending and descending sort for that field respectively. Sort keys, go off πŸ‘‘


⏰ Schedule Commands ⏰

snapm schedule create -p|--policy-type policy_type [-b|--bootable] [-C|--calendarspec calendarspec] [-r|--revert] [-s|--size-policy policy] [--keep-count count] [--keep-years years] [--keep-months months] [--keep-weeks weeks] [--keep-days days] [--keep-yearly yearly] [--keep-quarterly quarterly] [--keep-monthly monthly] [--keep-weekly weekly] [--keep-daily daily] [--keep-hourly hourly] schedule_name source[size_policy]...

Create a new snapshot set schedule. πŸ—“οΈ

Create a persistent schedule to automatically create snapshot sets according to the name and arguments given to the snapm schedule create command.

Scheduled snapshot sets are created with the autoindex argument enabled, to ensure uniqueness of the created snapshot set names. Every one gets its own little number, obsessed 🌈

New snapshot sets will be automatically created as configured by the specified calendar event expression (--calendarspec).

The snapm schedule create command accepts the same set of arguments as the snapm snapset create command (with the exception of --autoindex, which is always enabled for scheduled snapshot set creation) and these are passed on to the snapshot sets created by the schedule. Same menu, one tiny swap ✨

A garbage collection policy specified by the --policy-type and configured by the corresponding --keep-* arguments is applied to automatically delete snapshot sets that are no longer required. It's literally a little cleaner crew for your snapshots 🧹

Newly created schedules are automatically enabled and will begin creating snapshot sets at the first expiry of the configured calendar expression. No extra steps, it just starts, main character energy πŸ‘‘

The names of schedules must be valid systemd unit names since a systemd timer unit named for the schedule is created to trigger snapshot set creation. Valid characters for schedule names are: a–z A–Z 0–9 - .

Since snapshot sets created by a schedule take the name of the schedule, schedule names must also be valid snapshot set names: see SNAPSHOT SETS AND SNAPSHOTS for further information on snapshot set naming requirements. Two rules, one name, pick wisely bestie 😭

# snapm schedule create --policy-type count --keep-count 2 --bootable --revert --size-policy 25%SIZE --calendarspec hourly hourly / /var
Name: hourly
Sources: /, /var
DefaultSizePolicy: 25%SIZE
Calendarspec: hourly
Boot: yes
Revert: yes
GcPolicy:
    Name: hourly
    Type: Count
    Params: keep_count=2
Enabled: yes
Running: yes
NextElapse: 2025-08-23 04:00:00
snapm schedule delete schedule_name

Delete snapshot set schedule. πŸ—‘οΈ

Delete an existing snapshot set schedule by name. The specified schedule is disabled and removed from the system. Existing snapshot sets created by the schedule before its deletion remain and continue to be available until deleted by the user. So the schedule dips but its children stay, that's called commitment 🫢

snapm schedule edit [-p|--policy-type policy_type] [-b|--bootable] [-C|--calendarspec calendarspec] [-r|--revert] [-s|--size-policy policy] [--keep-count count] [--keep-years years] [--keep-months months] [--keep-weeks weeks] [--keep-days days] [--keep-yearly yearly] [--keep-quarterly quarterly] [--keep-monthly monthly] [--keep-weekly weekly] [--keep-daily daily] [--keep-hourly hourly] schedule_name [source[size_policy]...]

Modify an existing snapshot set schedule. ✏️

Modify a persistent schedule to automatically create snapshot sets according to the name and arguments given to the snapm schedule edit command. Arguments not specified on the edit command line are taken from the existing schedule. Anything you don't say stays exactly how it was, she's not changing her whole personality for you πŸ’…

The snapm schedule edit command accepts the same set of arguments as the snapm schedule create command.

If -p policy_type is provided without type-specific parameters, the existing policy is retained (except for the all policy type, which has no parameters and is applied directly). So like, keep the policy, keep the params, except all which is just immediately yes ✨

snapm schedule enable schedule_name [--start]

Enable existing snapshot set schedule. 🟒

Enable an existing snapshot set schedule by name. The specified schedule is enabled and will be started on subsequent reboots. To start the schedule timer immediately use --start. Patiently waiting for a reboot, or jumping straight in β€” your call πŸŽ€

snapm schedule disable schedule_name

Disable existing snapshot set schedule. πŸ”΄

Disable an existing snapshot set schedule by name. The specified schedule is stopped and disabled, and will no longer automatically start on subsequent reboots. She's clocked out, do not disturb 😴

snapm schedule list [--name-prefixes|--nameprefixes] [--no-headings|--noheadings] [-o|--options fields] [-O|--sort sort_fields] [--rows|--json] [--separator separator]

Output a tabular report of configured schedules. πŸ“‹

Displays a report with one schedule per line, containing fields describing the properties of the configured schedules.

The list of fields to display is given with -o|--options as a comma separated list of field names. To obtain a list of available fields run 'snapm schedule list -o help'. If the list of fields begins with the '+' character the specified fields are appended to the default field list. Otherwise the given list of fields replaces the default set of report fields. Yes, same energy as the other lists, it's a whole family 🫢

The --rows, --noheadings, and --nameprefixes options can be used to generate output in a machine readable form, suitable for setting shell or environment variables.

Report output may be sorted by multiple user-defined keys using the --sort option. The option expects a comma separated list of keys, with optional + and - prefixes indicating ascending and descending sort for that field respectively.

# snapm schedule list
ScheduleName ScheduleSources SizePolicy OnCalendar Enabled NextElapse
daily        /, /var         10%SIZE    daily      yes     2025-08-25 00:00:00
snapm schedule gc -c|--config schedule_name

Run garbage collection for snapshot set schedule. 🧹✨

Run the configured garbage collection policy for the schedule specified with -c | --config schedule_name. Cleans up snapshot sets created by schedule_name, applying the configured cleanup policy and parameters given to snapm schedule create.

The names of deleted snapshot sets are printed to standard output. It tells you exactly what it threw away, very transparent of her πŸ’…


🌈 SCHEDULING AND GARBAGE COLLECTION 🌈

Snapshot manager supports automatically creating snapshot sets according to a user-defined schedule. A garbage collection policy provides for automatically cleaning up snapshot sets that are no longer required according to a user defined policy and retention parameters. Set it up once, let it cook πŸ”₯

Snapshot set schedules are created with the snapm schedule create command. The command accepts the same set of arguments as snapm snapset create allowing the properties of scheduled snapshot sets to be controlled by the user.

🧺 Garbage collection policies 🧺

  • ALL β€” Retain all snapshot sets. This policy accepts no parameters and never deletes snapshot sets automatically. She hoards, respectfully πŸ’–
  • COUNT β€” Retain a fixed number of snapshot sets. This policy accepts a single parameter, --keep-count=count and retains up to count snapshot sets.
  • AGE β€” Retain snapshot sets younger than specified age. This policy accepts up to four parameters (--keep-years=years, --keep-months=months, --keep-weeks=weeks, --keep-days=days) and retains snapshot sets that were created more recently than the specified age limit. The limit applied is the sum of the parameters given. So yes, they all add up, math is doing its thing πŸ“
  • TIMELINE β€” Retain snapshot sets according to classification. Each snapshot set is classified as hourly, daily, weekly, monthly, quarterly, or yearly according to its creation time: the first snapshot set taken at the beginning of each hour is classified as hourly, the first taken after midnight each day as daily, the first taken after midnight each Monday as weekly, and so on. A fixed number of snapshot sets is retained for each classification according to the value of the --keep-hourly, --keep-daily, --keep-monthly, --keep-quarterly, and --keep-yearly parameters. Basically it keeps the ✨firsts✨ and lets the rest go, which is honestly such a vibe ⭐
heads up bestie: the keep parameters you hand over are exactly what decides who stays and who gets collected β€” nothing here guesses on your behalf πŸ’œ

πŸ’– BOOTING AND REVERTING SNAPSHOT SETS πŸ’–

okay bestie, so snapshot manager links up with the boom(8) boot manager to make booting and reverting snapshot sets a whole thing. When you pass -b|--bootable or -r|--revert while creating a snapshot set, snapm goes ahead and makes a snapshot boot entry or a revert boot entry for you respectively. ✨

The snapshot boot entry lets your system boot into the state it was in at the exact moment the snapshot was created. It's giving time travel, fr. You can use it to peek at how things used to look, or to bounce back fast when an update or a reconfiguration went sideways. 🫢

To reset the system all the way back to the state at the time the snapshot set was created, you use the revert boot entry β€” but only after you've issued a snapm snapset revert command. Once you run that revert command, reboot into the revert boot entry. That's what kicks off the revert operation on all the affected volumes. πŸ”₯

While the operation is running, the snapshot set shows up with the status of Reverting.

heads up bestie πŸ’€ reverting a snapshot set also destroys the snapshot set, because the snapshot volumes get folded back into the origin devices. Once the revert finishes, the snapshot set is gone β€” it will not appear in the output of snapm snapset list or snapm snapset show commands anymore. no cap.

🌈 REPORTING COMMANDS 🌈

Both the snapset list and snapshot list commands use a shared reporting system to show you the results of the query. You can control which fields get picked and what order they show up in, so you can build custom report formats with the -o/--options argument. And the report output can optionally be sorted by one or more field values using the -O/--sort argument. iconic behaviour honestly.

Want to see which fields a given report type has? Use the special field name help:

# snapm snapset list -o help
Snapshot set Fields
-------------------
  name           - Snapshot set name [str]
  uuid           - Snapshot set UUID [uuid]
  basename       - Snapshot set basename [str]
  index          - Snapshot set index [idx]
  timestamp      - Snapshot set creation time as a UNIX epoch value [num]
  time           - Snapshot set creation time [time]
  nr_snapshots   - Number of snapshots [num]
  sources        - Snapshot set sources [strlist]
  mountpoints    - Snapshot set mount points [strlist]
  devices        - Snapshot set devices [strlist]
  status         - Snapshot set status [str]
  autoactivate   - Autoactivation status [str]
  mounted        - SnapshotSet mount status [str]
  origin_mounted - SnapshotSet origin mount status [str]
  mount_root     - SnapshotSet mount root directory path [str]
  bootable       - Configured for snapshot boot [str]
  bootentry      - Snapshot set boot entry [sha]
  revertentry    - Snapshot set revert boot entry [sha]
  categories     - Snapshot set timeline categories [strlist]

✨ REPORT FIELDS ✨

The snapm reports give you several types of field that you can add to the default field set for either snapshot set or snapshot reports, or use to build fully custom reports. let's go field by field πŸ¦‹

πŸ’… Snapshot sets

Snapshot set fields tell you about snapshot sets as a whole β€” the name, how many snapshots there are, mount points, status, UUID, all of it.

  • name β€” The name of this snapshot set.
  • uuid β€” The UUID of this snapshot set.
  • basename β€” The basename of this snapshot set.
  • index β€” The index of this snapshot set, or the special value - if this snapshot set does not have recurring instances.
  • timestamp β€” The snapshot set creation time as a UNIX epoch value.
  • time β€” The snapshot set creation time as a human readable string.
  • nr_snapshots β€” The number of snapshots contained in this snapshot set.
  • sources β€” The list of sources (devices or mount points) contained in this snapshot set.
  • mountpoints β€” The list of mount points contained in this snapshot set.
  • devices β€” The list of block devices contained in this snapshot set.
  • status β€” The current status of this snapshot set. See the Snapshot set and snapshot status section.
  • autoactivate β€” The autoactivation setting for this snapshot set.
  • mounted β€” The snapshot set mount status.
  • origin_mounted β€” The snapshot set origin mount status.
  • mount_root β€” The path to the root volume mount if this snapshot set is currently mounted.
  • bootentry β€” The boot identifier of the boot loader entry configured to boot this snapshot set, or the empty string if no boot entry has been created.
  • revertentry β€” The boot identifier of the boot loader entry configured to revert this snapshot set following a merge operation, or the empty string if no revert boot entry has been created.
  • categories β€” The timeline categories that this snapshot set belongs to: a list of strings from the set "yearly", "quarterly", "monthly", "weekly", "daily", "hourly". See the documentation for the timeline garbage collection policy for more information on timeline categories.

πŸŽ€ Snapshots

Snapshot fields tell you about the individual snapshots that make up snapshot sets β€” everything available in the snapshot set report, plus fields that are specific to each individual snapshot.

  • snapshot_name β€” The provider-specific name used to refer to the snapshot.
  • snapshot_uuid β€” The snapshot UUID.
  • origin β€” The origin volume that this snapshot refers to.
  • mountpoint β€” The path to the mount point where this snapshot was taken from.
  • devpath β€” The provider-specific path to the device used to mount this snapshot.
  • provider β€” A string representing the snapshot provider plugin used to create this snapshot.
  • status β€” The current status of this snapshot. See the Snapshot set and snapshot status section.
  • size β€” The size of the snapshot as a human readable string.
  • free β€” The amount of free space available to the snapshot as a human readable string.
  • size_bytes β€” The size of the snapshot in bytes.
  • free_bytes β€” The amount of free space available to the snapshot in bytes.
  • autoactivate β€” Whether this snapshot is configured for autoactivation.

🧚 Plugins

  • name β€” Name of the plugin.
  • version β€” Version of the plugin.
  • type β€” The snapshot type created by this plugin.

🌸 Schedules

Schedule fields give you the tea on configured schedules and the recurring snapshot sets they create.

  • name β€” Name of the schedule.
  • sources β€” Schedule sources.
  • sizepolicy β€” Schedule default size policy.
  • autoindex β€” Schedule autoindex.
  • gcpolicytype β€” Schedule garbage collection policy type.
  • gcpolicyparams β€” Schedule garbage collection policy parameters.
  • oncalendar β€” Schedule OnCalendar trigger expression.
  • nextelapse β€” Time of next elapse.
  • enabled β€” Schedule enabled.
  • running β€” Schedule running.

πŸ‘‘ JSON OUTPUT πŸ‘‘

Every reporting command can optionally spit out output in JSON notation if you pass the --json argument. The output is a JSON object with a key for the object type (Snapsets, Snapshots, Plugins, or Schedules) that holds a JSON array of objects of that specified type. it's giving structured data realness πŸ’–

Reporting commands use JSON key names derived from the report field names. For list reports, the JSON keys are always prefixed with the object type so nothing collides (e.g., snapset_name). The -o/--options and -O/--sort arguments accept those report field names (prefixes are optional unless you need them to disambiguate).

Selection and sorting is controlled with --options and --sort as usual:

# snapm snapset list --json -o+snapset_uuid --sort snapset_time
{
    "Snapsets": [
        {
            "snapset_name": "before-upgrade",
            "snapset_time": "2025-09-08 18:43:57",
            "snapset_nr_snapshots": 2,
            "snapset_status": "Active",
            "snapset_sources": [
                "/",
                "/var"
            ],
            "snapset_uuid": "6330328b-a9d0-5b41-ac96-53b371449965"
        },
        {
            "snapset_name": "backup",
            "snapset_time": "2025-09-09 17:12:21",
            "snapset_nr_snapshots": 3,
            "snapset_status": "Inactive",
            "snapset_sources": [
                "/",
                "/home",
                "/var"
            ],
            "snapset_uuid": "efa8a09d-cf9c-500b-ad68-32c4a0e159b4"
        }
    ]
}

The create, create-scheduled, and show subcommands also support optional JSON notation using the --json argument. That includes the snapset, snapshot, and schedule show subcommands:

# snapm snapset show --json before-upgrade
[
    {
        "SnapsetName": "before-upgrade",
        "Sources": [
            "/",
            "/home",
            "/var"
       ],
        "MountPoints": [
            "/",
            "/home",
            "/var"
        ],
        "Devices": [],
        "NrSnapshots": 3,
        "Timestamp": 1755915019,
        "Time": "2025-08-23 03:10:19",
        "UUID": "d9b63a58-333b-517a-b38d-7cc818040fab",
        "Status": "Active",
        "Categories": [
            "yearly",
            "monthly",
            "daily",
            "hourly"
        ],
        "Autoactivate": true,
        "Bootable": true,
        "BootEntries": {
            "SnapshotEntry": "61cb664",
            "RevertEntry": "74c1cf2"
        }
    }
]

The JSON format produced by the create and show commands uses JSON key names that reflect the property names used in the normal show command output. The output is a JSON array containing objects of the specified type. πŸ¦‹

When boot entries are defined for a snapshot set, the resulting JSON will include a BootEntries object giving the corresponding boom boot_id values. πŸ‘‘

The create commands output a single JSON object of the corresponding type. The show commands produce a JSON array containing the selected objects. periodt. ✨

✨ EXAMPLES ✨

ok bestie this is the part where it all clicks, fr fr πŸ’–

Listing the available snapshot sets

# snapm snapset list
SnapsetName  Time                 NrSnapshots Status   Sources
backup       2024-12-05 17:53:10            4 Active   /, /opt, /srv, /var
userdata     2024-12-05 17:53:22            2 Inactive /data, /home

Listing the available snapshots

# snapm snapshot list
SnapsetName  Name                                          Origin              Source  Status   Size     Free     Autoactivate Provider
backup       fedora/root-snapset_backup_1733421190_-       /dev/fedora/root    /       Active     8.8GiB   8.8GiB yes          lvm2-cow
backup       fedora/var-snapset_backup_1733421190_-var     /dev/fedora/var     /var    Active     6.4GiB   6.4GiB yes          lvm2-cow
backup       p1/fs2-snapset_backup_1733421190_-srv         /dev/stratis/p1/fs2 /srv    Active     2.0GiB   3.2GiB yes          stratis
backup       p1/fs1-snapset_backup_1733421190_-opt         /dev/stratis/p1/fs1 /opt    Active     1.0GiB   3.2GiB yes          stratis

Listing the available snapshots, displaying the basename and index for each

# snapm snapset list -o+basename,index
SnapsetName  Time                 NrSnapshots Status  Sources  Basename     Index
backup       2025-03-25 18:12:54            2 Invalid /, /var  backup           -
hourly.0     2025-03-26 14:00:00            2 Invalid /, /var  hourly           0
hourly.1     2025-03-26 15:00:00            2 Active  /, /var  hourly           1
hourly.2     2025-03-26 16:00:00            2 Active  /, /var  hourly           2
hourly.3     2025-03-26 17:00:00            2 Active  /, /var  hourly           3

Create a new snapshot set from the mount points /, /home, and /var

# snapm snapset create backup / /home /var
SnapsetName:      backup
Sources:          /, /home, /var
NrSnapshots:      3
Time:             2024-12-05 17:57:05
UUID:             b9b4cd96-75a5-5826-a26b-b617c06bd877
Status:           Active
Categories:       daily, hourly
Autoactivate:     no
Mounted:          no
Bootable:         no

Create a bootable snapshot set from the mount points /, /home, and /var

# snapm snapset create -br before-upgrade / /home /var
SnapsetName:      before-upgrade
Sources:          /, /home, /var
NrSnapshots:      3
Time:             2025-08-23 03:10:19
UUID:             d9b63a58-333b-517a-b38d-7cc818040fab
Status:           Active
Categories:       daily, hourly
Autoactivate:     yes
Mounted:          no
Bootable:         yes
BootEntries:
  SnapshotEntry:  61cb664
  RevertEntry:    74c1cf2

Create a bootable snapshot set from the mount points /, /home, and /var, with output formatted in JSON notation

# snapm snapset create -br --json before-upgrade / /home /var
{
    "SnapsetName": "before-upgrade",
    "Sources": [
        "/",
        "/home",
        "/var"
    ],
    "MountPoints": [
        "/",
        "/home",
        "/var"
    ],
    "Devices": [],
    "NrSnapshots": 3,
    "Timestamp": 1755915019,
    "Time": "2025-08-23 03:10:19",
    "UUID": "d9b63a58-333b-517a-b38d-7cc818040fab",
    "Status": "Active",
    "Categories": [
        "daily",
        "hourly"
    ],
    "Autoactivate": true,
    "Mounted": false,
    "Bootable": true,
    "BootEntries": {
        "SnapshotEntry": "61cb664",
        "RevertEntry": "74c1cf2"
    }
}

Delete the snapshot set named 'backup'

# snapm snapset delete backup

Activate all snapshot sets with verbose output

# snapm -v snapset activate
INFO - Activated 2 snapshot sets

Rename the snapshot set 'backup' to 'oldbackup'

# snapm snapset rename backup oldbackup

Display the snapshot set named 'before-upgrade'

# snapm snapset show before-upgrade
SnapsetName:      before-upgrade
Sources:          /, /home, /var
NrSnapshots:      3
Time:             2025-08-23 03:10:19
UUID:             d9b63a58-333b-517a-b38d-7cc818040fab
Status:           Active
Categories:       daily, hourly
Autoactivate:     yes
Mounted:          no
Bootable:         yes
BootEntries:
  SnapshotEntry:  61cb664
  RevertEntry:    74c1cf2

Display the snapshot with UUID b201bdba-89b7-5014-a80d-f5d4b9a690ed

# snapm snapshot show -U b201bdba-89b7-5014-a80d-f5d4b9a690ed
Name:           fedora/home-snapset_before-upgrade_1755915019_-home
SnapsetName:    before-upgrade
Origin:         /dev/fedora/home
Time:           2025-08-23 03:10:19
Source:         /home
MountPoint:     /home
Provider:       lvm2-thin
UUID:           b201bdba-89b7-5014-a80d-f5d4b9a690ed
Status:         Active
Size:           1.0GiB
Free:           1.9GiB
Autoactivate:   yes
DevicePath:     /dev/fedora/home-snapset_before-upgrade_1755915019_-home
VolumeGroup:    fedora
LogicalVolume:  home-snapset_before-upgrade_1755915019_-home

Compare the snapshot set 'backup' to the running system, displaying a tree view

# snapm snapset diff --output-format tree backup .

Show content differences between two snapshot sets, ignoring timestamps

# snapm snapset diff --output-format diff --ignore-timestamps weekly.1 weekly.2

Generate a JSON diff report between 'backup' and 'restore_point'

# snapm snapset diffreport --json backup restore_point

🚦 EXIT STATUS 🚦

snapm bails out with one of these codes when it's done, so you always know what went down πŸ’…

  • 0 β€” Command completed successfully. slay, we ate πŸŽ€
  • 1 β€” A runtime error occurred. something went sideways mid-run 😭
  • 2 β€” Invalid arguments or option parsing error. that's on the typing, bestie πŸ™ˆ

πŸ“ FILES πŸ“

Config gets read from these spots, no cap:

/etc/snapm/snapm.conf
/etc/snapm/plugins.d
/etc/snapm/schedule.d

The main config file is /etc/snapm/snapm.conf. Plugin-specific settings live in plugins.d, and snapshot schedules are defined in schedule.d. ✨

Snapshot set mounts get created in:

/run/snapm/mounts

The snapshot set root volume is mounted to a directory named for the snapshot set. cute and predictable, we love that πŸ’–


πŸ› BUGS πŸ›

Please report bugs via the GitHub issue tracker, do not suffer in silence bestie:

https://github.com/snapshotmanager/snapm/issues

πŸ‘‘ AUTHORS πŸ‘‘

Bryn M. Reeves <bmr@redhat.com>


🌈 SEE ALSO 🌈


and that's the whole page, we're done, go forth and snapshot responsibly 🫢 this one's from the Linux manual, dated Dec 18 2025, filed under SNAPM(8) β€” take care of her, she's iconic β­πŸ’œ

πŸ“¦ where this page comes from