SNAPM(8)
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-expiresexpire_secs β set the diff cache expiry time in seconds.0disables expiry entirely. the default is900seconds (15 minutes). heads up: this one is mutually exclusive with--cache-modeβ pick a lane, bestie π-C,--calendarspeccalendarspec β the calendar event expression that triggers scheduled creation of snapshot sets. peepsystemd.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 π--colormode β (Diff) turns on colored output. valid modes areauto,never, andalways. rainbows on demand π-c,--configschedule_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,--debugdebug_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,--descmode β (Diff) include change description in tree output. valid modes arenone,short, andfull.-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-patternpattern β (Diff) file patterns to include in comparison (glob notation).--jsonβ produce output in JSON notation. see the JSON OUTPUT section.--keep-countcount β retain count snapshot sets when applying theCOUNTgarbage collection policy.--keep-yearsyears β retain years snapshot sets when applying theAGEgarbage collection policy.--keep-monthsmonths β retain months snapshot sets when applying theAGEgarbage collection policy.--keep-weeksweeks β retain weeks snapshot sets when applying theAGEgarbage collection policy.--keep-daysdays β retain days snapshot sets when applying theAGEgarbage collection policy.--keep-yearlyyearly β retain yearly yearly snapshot sets when applying theTIMELINEgarbage collection policy.--keep-quarterlyquarterly β retain quarterly quarterly snapshot sets when applying theTIMELINEgarbage collection policy.--keep-monthlymonthly β retain monthly monthly snapshot sets when applying theTIMELINEgarbage collection policy.--keep-weeklyweekly β retain weekly weekly snapshot sets when applying theTIMELINEgarbage collection policy.--keep-dailydaily β retain daily daily snapshot sets when applying theTIMELINEgarbage collection policy.--keep-hourlyhourly β retain hourly hourly snapshot sets when applying theTIMELINEgarbage collection policy.-H,--max-hash-sizesize β (Diff) maximum file size for generating content hashes (default:1MiB).-m,--max-file-sizesize β (Diff) maximum file size for comparisons (0=unlimited).-M,--cache-modecache_mode β specify diff caching mode (auto,never,always). the default (auto) automatically expires the diff cache after900seconds (15 minutes). usingalwaysdisables cache expiry. to disable the use of the cache entirely, usenever. and this option is mutually exclusive with--cache-expiresβ fr fr, one or the other π--membersβ include individual snapshots in the output ofsnapset showcommands. show me everyone π«Ά-n,--namename β 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--noheadingsto produce a list offield=valuepairs 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,--optionsfields β specify which fields to display.-o,--output-formatformat β (Diff) output format for diff data. valid formats arepaths,full,short,json,diff,summary, andtree. this option may be specified multiple times to print different output formats for the same run. the default if--output-formatis not specified istree. the way that you can stack these... obsessed πΈ-O,--sortsort_fields β specify which fields to sort by.-s,--start-pathpath β (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 indiffandsummaryoutput.-p,--ignore-permissionsβ (Diff) ignore permissions when computing diffs.-p,--policy-typepolicy_type β select the garbage collection policy applied to snapshot sets created by a schedule. valid values areALL,COUNT,AGE, andTIMELINE.-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 π--separatorseparator β report field separator.-s,--size-policysize_policy β specify a default size policy when creating snapshot sets.-N,--snapshot-namename β specify a snapshot name to operate on.-U,--snapshot-uuidUUID β specify a snapshot UUID to operate on.--startβ start the specified schedule immediately when enabling it withsnapm schedule enable. no waiting, we go now π₯-t,--ignore-timestampsβ (Diff) ignore timestamps when computing diffs.-u,--uuidUUID β 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 ofsnapmand exit.-w,--ignore-ownershipβ (Diff) ignore ownership when computing diffs.-x,--exclude-patternpattern β (Diff) file patterns to exclude from comparison (glob notation).-z,--max-diff-sizesize β (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 bydf. 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--quietargument. π
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,activateanddeactivatehave 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 providersactivateanddeactivatehave 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,activateanddeactivatehave 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 providersactivateanddeactivatehave 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=countand retains up tocountsnapshot 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-yearlyparameters. 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 ofsnapm snapset listorsnapm snapset showcommands 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 π
snapm.conf(5).snapm-plugins.d(5).snapm-schedule.d(5).systemd.time(7).boom(8).lvm(8).stratis(8).- snapm project page
- snapm user guide
- snapm API documentation
- Boom project page
- LVM2 resource page
- Stratis resource page
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
- centos-stream 10: snapm 0.7.0-5.el10 Β· Apache-2.0
- centos-stream 9: snapm 0.7.0-5.el9 Β· Apache-2.0
- fedora 43: snapm 0.7.0-4.fc43 Β· Apache-2.0
- fedora 44: snapm 0.7.0-5.fc44 Β· Apache-2.0
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms