-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathatom.xml
More file actions
2134 lines (2080 loc) · 265 KB
/
atom.xml
File metadata and controls
2134 lines (2080 loc) · 265 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
<title>Snapshot Manager</title>
<subtitle>Easy to use snapshot management for Linux.</subtitle>
<link rel="self" type="application/atom+xml" href="https://snapshotmanager.github.io/atom.xml"/>
<link rel="alternate" type="text/html" href="https://snapshotmanager.github.io"/>
<generator uri="https://www.getzola.org/">Zola</generator>
<updated>2026-01-20T00:00:00+00:00</updated>
<id>https://snapshotmanager.github.io/atom.xml</id>
<entry xml:lang="en">
<title>Frequently Asked Questions (FAQs)</title>
<published>2026-01-20T00:00:00+00:00</published>
<updated>2026-01-20T00:00:00+00:00</updated>
<author>
<name>
Unknown
</name>
</author>
<link rel="alternate" type="text/html" href="https://snapshotmanager.github.io/blog/faq/"/>
<id>https://snapshotmanager.github.io/blog/faq/</id>
<content type="html" xml:base="https://snapshotmanager.github.io/blog/faq/"><h1 id="frequently-asked-questions-faqs">Frequently Asked Questions (FAQs)</h1>
<p>Our users ask a lot of reasonable and insightful questions about <code>snapm</code> and its usage. We have collected together some of the more common ones in this post, along with their corresponding answers.</p>
<h2 id="running-snapshot-manager">Running Snapshot Manager</h2>
<p><strong>Q:</strong> What Python version does snapm require?<br />
<strong>A:</strong> We support Python 3.9 and later.</p>
<p><strong>Q:</strong> Do you support other operating systems than Linux?<br />
<strong>A:</strong> No, and this is unlikely to change: the snapshot providers that we support are all Linux specific.</p>
<p><strong>Q:</strong> Is my distribution supported?<br />
<strong>A:</strong> The <code>snapm</code> command and <code>boom-boot</code> should work on most recent Linux distributions (using <code>boom</code> to create bootable snapshot sets requires a <a href="https://uapi-group.org/specifications/specs/boot_loader_specification/"><em>BLS compatible</em></a> boot loader: some versions of GRUB2, the zSeries zIPL, or <a href="https://man7.org/linux/man-pages/man7/systemd-boot.7.html"><code>systemd-boot(7)</code></a>). Distribution packages are currently available for, and are tested on, Fedora, CentOS Stream, and Red Hat Enterprise Linux.</p>
<p><strong>Q:</strong> Can I use snapm on systems without LVM?<br />
<strong>A:</strong> Snapshot Manager supports LVM2 (CoW and thin) snapshots as well as Stratis snapshots. Other storage back ends (for example, Btrfs) may be supported in future versions.</p>
<h2 id="using-snapshot-manager">Using Snapshot Manager</h2>
<p><strong>Q:</strong> What's the difference between a Snapshot and a Snapshot Set?<br />
<strong>A:</strong> A Snapshot is an individual instance of a block device or file system snapshot (managed by <code>snapm</code> or not, as the case may be). A Snapshot Set is a named collection of snapshots taken at the same point in time and managed by <code>snapm</code>.</p>
<p><strong>Q:</strong> Can I use the difference engine if I haven't created any snapshot sets yet?<br />
<strong>A:</strong> No: it is only possible to create difference reports when there is at least one snapshot set to make a comparison against.</p>
<p><strong>Q:</strong> Do I need to use <code>boom</code> in order to use <code>snapm</code>?<br />
<strong>A:</strong> We require <code>boom</code> to create bootable snapshot sets but you don't need to interact with it directly (you don't even need to install the <code>boom-boot</code> CLI, but it can be useful for inspecting your boot entries). Unless you have unusual requirements the <code>snapm</code> tool can take care of all the details for you when you use the <code>--boot</code> or <code>--revert</code> options.</p>
<h2 id="snapshot-set-creation-and-management">Snapshot Set Creation and Management</h2>
<p><strong>Q:</strong> How much space do I need for snapshots?<br />
<strong>A:</strong> That is a bit of a ‘how long is a piece of string?’ question: the precise answer depends on the amount of change that occurs to the origin volume or the snapshot during its lifespan. Snapshot Manager has built-in default size policies when creating snapshot sets, but if you have a better estimate then these values should be adjusted for your particular circumstances: the default size policy is different depending on whether you are creating a snapshot from a mount point source or a block device source. For mount points the default size policy specifies twice the space currently used on the mount point (‘200%USED’ in size policy notation). For block devices it is one quarter the physical size of the device (‘25%SIZE’)</p>
<p><strong>Q:</strong> What happens if a snapshot runs out of space?<br />
<strong>A:</strong> This will produce errors and may invalidate the snapshot. This should be avoided as the snapshot will be rendered unusable: this will result in data loss.</p>
<p><strong>Q:</strong> Can I create snapshots of individual files or directories?<br />
<strong>A:</strong> No: none of the current snapshot providers support snapshots at this granularity. A similar result can be obtained on modern file systems via the <em>reflink</em> facility (see <a href="https://man7.org/linux/man-pages/man1/cp.1.html"><code>cp(1)</code></a>) but these snapshot-like file system objects are not managed by <code>snapm</code>.</p>
<p><strong>Q:</strong> Can I modify the contents of a snapshot after creation?<br />
<strong>A:</strong> Yes. Snapshot sets are by default created in read-write mode and can be modified when mounted subject to normal file system permission checks.</p>
<p><strong>Q:</strong> Why does my snapshot set show as "<code>Reverting</code>" and how long will it take?<br />
<strong>A:</strong> This is because a <code>snapset revert</code> command has been issued (or the underlying storage tools have been used to initiate a revert). The time it takes depends on the snapshot provider type: in all cases, when snapshots or their origin volumes are in use, the revert operation is deferred until the next activation (normally at boot time). In the case of LVM2 CoW snapshots the underlying merge operation involves physically moving dat<strong>A:</strong> this takes time proportional to the amount of data in the snapshot at the time of the merge and the speed of the storage devices involved. Thin snapshot reverts (LVM2 Thin and Stratis) are instantaneous at the time the pool is activated.</p>
<h2 id="scheduling-clean-up">Scheduling &amp; Clean-up</h2>
<p><strong>Q:</strong> How do I know which garbage collection policy to use?<br />
<strong>A:</strong> This depends on how much space you have, and for how long you want to keep snapshot sets around. The four policies (<code>ALL</code>, <code>COUNT</code>, <code>AGE</code>, <code>TIMELINE</code>) cover a multitude of possibilities and accept parameters to configure them for your needs. See the <code>snapm(8)</code> manual page for a full description of configuring and managing schedules.</p>
<p><strong>Q:</strong> Will scheduled snapshots fill up my disk?<br />
<strong>A:</strong> Potentially, yes. The thin provisioned snapshot providers are more space efficient than the LVM2 CoW provider but they will consume space from the pool they are created in (unlike LVM2 CoW which will not exceed the fixed space allocated to it from its containing volume group). You should configure a garbage collection policy with parameters that limit space consumption to an acceptable level.</p>
<p><strong>Q:</strong> What happens to my snapshots if I delete a schedule?<br />
<strong>A:</strong> The snapshot sets will remain until they are manually deleted.</p>
<p><strong>Q:</strong> Can I manually delete snapshot sets created by a schedule?<br />
<strong>A:</strong> Yes: use the regular <code>snapm snapset delete</code> command with the name or UUID of the snapshot set you want to remove. The schedule garbage collection policy will continue to operate as configured.</p>
<h2 id="boot-recovery">Boot &amp; Recovery</h2>
<p><strong>Q:</strong> What's the difference between <code>-b/--bootable</code> and <code>-r/--revert</code>?<br />
<strong>A:</strong> The <code>-b/--bootable</code> option creates a bootable snapshot set. When you select the resulting Snapshot boot entry the snapshot set will boot in place of the normal system environment, allowing you to look around and make changes. The <code>-r/--revert</code> option is used to create a fail safe revert boot entry. This is used in conjunction with the <code>snapm snapset revert</code> command to revert the system to the state reflected in the snapshot set. The revert boot entry uses backup boot images by default to protect against the case where the original copies have already been removed from the live system. See the <code>snapm(8)</code> manual page for full instructions on using Snapshot Manager's boot integration features.</p>
<p><strong>Q:</strong> Can I boot into a snapshot set without reverting to it?<br />
<strong>A:</strong> Yes. Select the appropriate Snapshot boot entry from your system's boot menu to boot into the corresponding snapshot set. Subsequently, when you reboot, the system will by default boot into the normal (non snapshot) environment.</p>
<p><strong>Q:</strong> What happens if I reboot while a revert is in progress?<br />
<strong>A:</strong> The revert will continue the next time that its volumes are activated.</p>
<p><strong>Q:</strong> Do I need to create boot entries manually?<br />
<strong>A:</strong> No: use the <code>-b/--bootable</code> and <code>-r/--revert</code> options when creating snapshot sets and <code>snapm</code> will take care of the necessary details.</p>
<h2 id="compatibility-integration">Compatibility &amp; Integration</h2>
<p><strong>Q:</strong> Can I use regular storage commands on snapm managed volumes?<br />
<strong>A:</strong> Yes: you are free to mix LVM2 or Stratis commands with your <code>snapm</code> commands. Just don't rename the logical volumes or Stratis file systems (or <code>snapm</code> will no longer recognise them as snapshot set members).</p>
<p><strong>Q:</strong> Will snapm interfere with my existing LVM2 or Stratis snapshots?<br />
<strong>A:</strong> No: snapm will not touch any snapshots that it did not create.</p>
<p><strong>Q:</strong> Does snapm work with Stratis or other storage systems?<br />
<strong>A:</strong> Yes: snapm currently supports LVM2 and Stratis with native (in tree) plugins. Support for Btrfs will be added in a future version.</p>
<p><strong>Q:</strong> Can I use snapm with encrypted volumes?<br />
<strong>A:</strong> ‘It depends’: <code>snapm</code> currently supports LVM2 volume groups that are encrypted at the physical volume level (encrypted VGs) as well as encrypted Stratis pools. Support for individually encrypted LVM2 logical volumes will be included in a future release: see <a href="https://github.com/snapshotmanager/snapm/issues/916">Issue #916</a> for more information.</p>
<h2 id="performance-safety">Performance &amp; Safety</h2>
<p><strong>Q:</strong> Does creating snapshots impact system performance?<br />
<strong>A:</strong> Potentially, yes. This is particularly acute when you have multiple LVM2 CoW snapshots of the same volume. In this case performance is significantly degraded when more than a handful of snapshots exist.</p>
<p><strong>Q:</strong> Is it safe to snapshot a running database?<br />
<strong>A:</strong> It depends on your definition of ‘safe’: the resulting snapshot will be internally consistent at the file system level but the database data will almost certainly not be <em>application consistent</em>. See the next question for more information. We are in the process of creating documentation to discuss this important topic in greater detail.</p>
<p><strong>Q:</strong> What level of consistency do snapshots provide?<br />
<strong>A:</strong> It depends on how and when they are taken and whether the system was prepared for the snapshot beforehand. Snapshots are always <em>file system consistent</em> due to the mechanisms used by the kernel but achieving <em>application consistency</em> currently depends on the administrator to stop services or isolate to a <code>systemd</code> target such as <code>rescue</code> before creating snapshot sets.</p>
<p><strong>Q:</strong> Can snapshots protect against hardware failure?<br />
<strong>A:</strong> Snapshots live on the same storage as your data. A catastrophic hardware failure may affect both your main volumes and your snapshots. For this reason we always recommend combining snapm use with a carefully designed and tested backup strategy.</p>
<h2 id="troubleshooting">Troubleshooting</h2>
<p><strong>Q:</strong> Why can't I mount my snapshot set?<br />
<strong>A:</strong> First check the snapshot set is not <code>Invalid</code> by examining the <code>Status</code> field in the output of <code>snapm snapset list</code>. If this is the case then the volume will be inaccessible (and difficult to repair — recovery of an invalid CoW exception store is beyond the scope of this FAQ). If the snapshot is valid check the output of <a href="https://man7.org/linux/man-pages/man1/dmesg.1.html"><code>dmesg(1)</code></a> or <a href="https://man7.org/linux/man-pages/man1/journalctl.1.html"><code>journalctl(1)</code></a> and consider consulting the <a href="https://man7.org/linux/man-pages/man8/fsck.8.html"><code>fsck(8)</code></a> program for your file system (preferably, to start, in check/read only/dry run mode if supported).</p>
<p>Note that if you are trying to mount a snapshot of an <a href="https://man7.org/linux/man-pages/man5/xfs.5.html"><code>xfs(5)</code></a> file system while its origin volume is also mounted you will need to specify <code>-o nouuid</code> when running the <a href="https://man7.org/linux/man-pages/man8/mount.8.html"><code>mount(8)</code></a> program to avoid a UUID collision.</p>
<p><strong>Q:</strong> My <code>diff</code> or <code>diffreport</code> command is taking forever — is this normal?
<strong>A:</strong> The time taken for difference computation is proportional to the size of the file system (number of files and directories) and the degree of change between the volumes being compared. It is normal for difference calculations for large volumes with many changes to take some time (minutes to tens of minutes for very large file systems). You may be able to gain more insight into what is happening by enabling verbose logs and debugging. Refer to the <code>snapm(8)</code> manual page for details of available debug and logging settings.</p>
</content>
</entry>
<entry xml:lang="en">
<title>Your First Snapshot Set</title>
<published>2026-01-20T00:00:00+00:00</published>
<updated>2026-01-20T00:00:00+00:00</updated>
<author>
<name>
Unknown
</name>
</author>
<link rel="alternate" type="text/html" href="https://snapshotmanager.github.io/blog/your-first-snapshot-set/"/>
<id>https://snapshotmanager.github.io/blog/your-first-snapshot-set/</id>
<content type="html" xml:base="https://snapshotmanager.github.io/blog/your-first-snapshot-set/"><h1 id="your-first-snapshot-set">Your First Snapshot Set</h1>
<p>A snapshot set is a collection of snapshots, bound together with a name, and created at a common point in time<sup class="footnote-reference" id="fr-1-1"><a href="#fn-1">1</a></sup>. At a bare minimum, to create one, you just need a name and a list of sources (<em>mount points</em> or <em>block devices</em>) that you would like to include in the set. More advanced options exist to give additional control over the creation process and the resulting snapshot set: we will cover these in detail in future blog posts.</p>
<h2 id="choosing-sources-first-things-to-know">Choosing Sources: First Things to know</h2>
<p>Before you can create your first snapshot set you'll need to ensure that you have everything necessary in place:</p>
<ul>
<li>
<p>You need snapshot capable storage: LVM2 regular or thin provisioned volumes, or Stratis file systems.</p>
</li>
<li>
<p>You need free space for your snapshots to use (either in an LVM2 volume group with regular volumes, or in the thin pool containing the volumes with LVM2 Thin provisioning or Stratis storage).</p>
</li>
<li>
<p>You'll need to know the mount point or block device path for the volumes you wish to include in your snapshot set.</p>
</li>
<li>
<p>You need <code>snapm</code>.</p>
</li>
</ul>
<p>For your first experiment, it doesn't matter what you snapshot as long as it meets these criteria. Later, when you are using the tool in anger, you can craft specific commands for different use cases or automate the process via schedules. To get the most from this exercise, it is helpful to be able to make some changes to whatever you snapshot so you'll have genuine differences to examine.</p>
<p>If you haven't already installed the <code>snapm</code> command on your system read <a href="https://snapshotmanager.github.io/blog/getting-snapm/">Getting <code>snapm</code></a> and follow the instructions there: then return here to continue.</p>
<p>Sources for Snapshot Manager can be either <strong>mount points</strong>, or <strong>block devices</strong>. A <em>mount point</em> source corresponds to a mounted file system. You can specify it either by mount point path (for example, <code>/home</code>) or by the underlying block device path (for example, <code>/dev/vg0/home</code>). A <em>block device source</em> is a block device that is not mounted and that need not contain a mountable file system image (for example, databases, virtual machine images, and other non file system content).</p>
<p>Snapshot Manager uses the mechanism of <em>provider plugins</em> to support different types of storage. A <strong>provider plugin</strong> corresponds to a particular storage technology (LVM2 CoW, LVM2 Thin, Stratis, and so on). The <code>snapm</code> command will determine the correct plugins to use for any given source (assuming that one exists and is able to snapshot the requested volume) — you do not need to specify which plugins to use on the command line.</p>
<p>Some familiarity with your storage stack's management tools will help when it comes to planning, monitoring, and finding your way around (whether that's <a href="https://man7.org/linux/man-pages/man8/vgs.8.html"><code>vgs(8)</code></a>, <a href="https://man7.org/linux/man-pages/man8/lvs.8.html"><code>lvs(8)</code></a>, et al. for <strong>LVM2</strong>, or the <a href="https://www.mankier.com/8/stratis"><code>stratis(8)</code></a> command line tool for <strong>Stratis storage</strong>). Knowledge of common Linux administrative tools like the <a href="https://man7.org/linux/man-pages/man8/mount.8.html"><code>mount(8)</code></a> program, <a href="https://man7.org/linux/man-pages/man8/findmnt.8.html"><code>findmnt(8)</code></a>, <a href="https://man7.org/linux/man-pages/man8/lsblk.8.html"><code>lsblk(8)</code></a>, and <a href="https://man7.org/linux/man-pages/man8/blkid.8.html"><code>blkid(8)</code></a> will also be an advantage — refer to the respective manual pages for more details, or check out one of the many great Linux systems administration tutorials available on the internet.</p>
<h2 id="naming-your-snapshot-set">Naming Your Snapshot Set</h2>
<p>You are free to name your snapshot set anything you like within the constraints enforced by <code>snapm</code> and its provider plugins:</p>
<ol>
<li>
<p>The <code>_</code> (underscore) character is not permitted.</p>
</li>
<li>
<p>The valid characters for snapshot set names are the ASCII lowercase and uppercase alphabetic characters, the digits, and the symbols <code>.</code>, <code>+</code>, and <code>-</code>.</p>
</li>
<li>
<p>Certain strings may be forbidden by particular provider plugins: for instance, LVM2 reserves the string <code>_mlog</code> (and others) for internal logical volume names (refer to <a href="https://man7.org/linux/man-pages/man8/lvm.8.html"><code>lvm(8)</code></a>, <a href="https://man7.org/linux/man-pages/man7/lvmraid.7.html"><code>lvmraid(7)</code></a> and related manual pages for more information).</p>
</li>
<li>
<p>Certain providers may enforce a maximum name length, for example, for LVM2 volumes this is 127 characters. Note that this limit includes parts of the internal name generated by <code>snapm</code> (which varies according to the mount point the snapshot refers to), so the usable name length is somewhat shorter. Nobody likes long device names anyway so this should not be a concern in most situations.</p>
</li>
<li>
<p>Any provider that represents the snapshot name as an entry in the file system (which includes all current and planned snapshot providers) is naturally limited by the maximum allowed file name length on Linux (255 characters). Again, this absolute maximum is reduced somewhat by the need for <code>snapm</code> to encode various information into the names it generates.</p>
</li>
<li>
<p>If you include a <code>.</code> followed by a nonnegative number at the end of your snapshot set name <code>snapm</code> will consider it to be an index. This is useful when taking recurring snapshots sets of the same things with a common base name. You can also have <code>snapm</code> add one automatically using the <code>--autoindex</code> option (more on that in a later post).</p>
</li>
<li>
<p>it is generally best to not include a date or time reference in the name unless you really, really want to: <code>snapm</code> already stores the creation time of the snapshot set as a UNIX epoch timestamp value and renders it as human readable date and time strings in the local time zone.</p>
</li>
<li>
<p>The name <code>.</code> is reserved by snapm for referencing the live root file system.</p>
</li>
</ol>
<p>Aim for memorable and meaningful names: <code>quux-foo-backup</code> might seem like a good idea at the time, when you're typing in a hurry, but future you will thank present you for coming up with something more self-explanatory.</p>
<p>Good names might be:</p>
<ul>
<li>
<p><code>before-upgrade</code></p>
</li>
<li>
<p><code>after-upgrade</code></p>
</li>
<li>
<p><code>pre-deployment</code></p>
</li>
<li>
<p><code>post-deployment</code></p>
</li>
<li>
<p><code>hourly.N</code> (where <code>N</code> is an integer uniquifying index either appended manually or enabled automatically with <code>--autoindex</code> - see <code>snapm(8)</code>)</p>
</li>
</ul>
<p>Bad names would include:</p>
<ul>
<li>
<p><code>backup</code></p>
</li>
<li>
<p><code>thing</code></p>
</li>
<li>
<p><code>thisone</code></p>
</li>
<li>
<p><code>thatone</code></p>
</li>
<li>
<p><code>something-something-something-snapshot-side</code></p>
</li>
<li>
<p><code>foo</code>, <code>fubar</code>, <code>plugh</code>, <code>quux</code>, <code>qwerty</code>, <code>thud</code>, <code>xyzzy</code>, etc.</p>
</li>
</ul>
<h2 id="overriding-the-default-size-policy">Overriding The Default Size Policy</h2>
<p>Snapshot Manager provides size policies that allow the user to request that a certain amount of space be available when creating snapshots. For some providers (LVM2 Thin, Stratis) this is simply a check that this space is available at the time the snapshot set is created. For LVM2 CoW it determines the actual size of the snapshot exception store that the tool will allocate.</p>
<p>The default size policy is different depending on whether you are creating a snapshot from a mount point source or a block device source. For mount points the default size policy specifies twice the space currently used on the mount point (<code>200%USED</code> in size policy notation). For block devices it is one quarter the physical size of the device (<code>25%SIZE</code>).</p>
<p>To override these defaults, either append a colon and size policy to individual sources (<code>:POLICY</code>) or use <code>--size-policy=POLICY</code> for all sources without explicit policies.</p>
<p>For example:</p>
<ul>
<li>
<p><code>/:2GiB</code> — specify a source of <code>/</code> (the root file system) with a fixed 2GiB size policy</p>
</li>
<li>
<p><code>/:100%SIZE /home:50%SIZE</code> — specify sources for root and home with a policy requesting 100% and 50% of their respective device sizes</p>
</li>
<li>
<p><code>--size-policy=100%SIZE</code> — set the policy for all sources not otherwise specified on the command line to be 100% of the corresponding device size</p>
</li>
</ul>
<h2 id="the-snapm-snapset-create-command">The <code>snapm snapset create</code> command</h2>
<p>With the basics explained it's time to actually create a snapshot set with the <code>snapm snapset create</code> command. Take your chosen name and list of sources and append them to the command line, then hit Enter to run the program and create the snapshot set:</p>
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span># snapm snapset create my-first-set / /var
</span><span>SnapsetName: my-first-set
</span><span>Sources: /, /var
</span><span>NrSnapshots: 2
</span><span>Time: 2026-01-13 12:44:12
</span><span>UUID: 0ea16412-8ceb-59d4-af0b-9afa79d306e9
</span><span>Status: Inactive
</span><span>Categories: daily, hourly
</span><span>Autoactivate: no
</span><span>OriginMounted: yes
</span><span>Mounted: no
</span><span>Bootable: no
</span></code></pre>
<p>That's all there is to it! Before we conclude let's take a brief look at the output the tool produces:</p>
<ul>
<li>
<p><code>SnapsetName</code> — the name you gave to the snapshot set</p>
</li>
<li>
<p><code>Sources</code> — the list of sources (minus any size policy that was specified on the command line)</p>
</li>
<li>
<p><code>NrSnapshots</code> — the number of snapshots contained in this set</p>
</li>
<li>
<p><code>Time</code> — the time and date the snapshot set was created in your local time zone</p>
</li>
<li>
<p><code>UUID</code> — a unique identifier for the snapshot set (a Version 5 UUID to be exact<sup class="footnote-reference" id="fr-2-1"><a href="#fn-2">2</a></sup>)</p>
</li>
<li>
<p><code>Status</code> — the status of this snapshot set: one of <code>Active</code>, <code>Inactive</code>, <code>Invalid</code>, or <code>Reverting</code>)</p>
</li>
<li>
<p><code>Categories</code> — the timeline categories that this snapshot set belongs to: we will cover timeline categories, scheduling, and automatic garbage collection in a future blog post.</p>
</li>
<li>
<p><code>Autoactivate</code> — whether automatic boot time activation is enabled for this snapshot set: <code>yes</code> or <code>no</code></p>
</li>
<li>
<p><code>OriginMounted</code> — the mount status of this snapshot set's origin devices: <code>yes</code> or <code>no</code></p>
</li>
<li>
<p><code>Mounted</code> — the mount status of this snapshot set: <code>yes</code> or <code>no</code></p>
</li>
<li>
<p><code>Bootable</code> — whether this snapshot set has <a href="https://www.mankier.com/8/boom"><code>boom(8)</code></a> boot entries or not: <code>yes</code> or <code>no</code></p>
</li>
</ul>
<p>We will get to all of these properties and their precise meaning in good time, but for now the <code>Status</code> field deserves a little more explanation: some snapshot providers (LVM2 Thin, Stratis) support optional activation for snapshot devices.</p>
<p>This means that you don't have snapshot devices cluttering the system and using resources when they are not required and is therefore more efficient — especially when dealing with very large numbers of snapshots. For LVM2 CoW the snapshot volume must be active at all times that the origin is active.</p>
<p>If your snapshot set includes thin snapshots (LVM2 Thin or Stratis) then it will begin its life in the <code>Inactive</code> state<sup class="footnote-reference" id="fr-3-1"><a href="#fn-3">3</a></sup>. If it only includes LVM2 CoW snapshots then it will begin in the <code>Active</code> state (and cannot, in fact, become <code>Inactive</code> unless the origin volume is also inactive).</p>
<p>If you receive an error message instead of the expected output shown above study it carefully to try to understand what it is telling you. Most error conditions have a clear message that explains exactly what is wrong. The most common error is ‘not enough space’: if you run into this you will see a message like this rather than the snapshot set summary:</p>
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span># snapm snapset create my-first-set / /var
</span><span>ERROR - Error creating lvm2-cow snapshot: Volume group fedora has insufficient free space to snapshot / (14.5GiB &lt; 15.1GiB)
</span><span>ERROR - Command failed: Insufficient free space for snapshot set my-first-set
</span></code></pre>
<p>If this happens you can resolve the problem in one of these three ways:</p>
<ul>
<li>
<p>Add more space to the volume group or thin pool</p>
</li>
<li>
<p>Delete one or more unneeded volumes to reclaim space</p>
</li>
<li>
<p>Change the size policy to create a smaller snapshot</p>
</li>
</ul>
<p>If you receive some other error refer to the <code>snapm(8)</code> manual page and the <a href="https://snapshotmanager.github.io/blog/faq/">FAQ</a>: you may find that your problem already has a straightforward answer. If not then you can reach out to your distribution's support channels or the developers for assistance<sup class="footnote-reference" id="fr-4-1"><a href="#fn-4">4</a></sup>.</p>
<h2 id="care-and-feeding-of-your-snapshot-set">Care and Feeding of Your Snapshot Set</h2>
<p>Now that you have a snapshot set that captures the state of your system at some moment in time you need to know how to look after it. This is essentially the same task as you would need to carry out for any other volume managed with your tool of choice. The major point to bear in mind is that both thin and LVM2 CoW snapshots can run out of space. It is important to ensure that this does not happen for the reasons explained in the <a href="https://snapshotmanager.github.io/blog/faq/#performance-safety">Performance &amp; Safety section of the Snapshot Manager FAQ</a>.</p>
<p>As an example, using the snapshot set created in the previous step we see the following output when running the <a href="https://man7.org/linux/man-pages/man8/lvs.8.html"><code>lvs(8)</code></a> program<sup class="footnote-reference" id="fr-5-1"><a href="#fn-5">5</a></sup>:</p>
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span># lvs -o lv_name,lv_size,data_percent
</span><span>LV LSize Data%
</span><span>root 10.00g
</span><span>root-snapset_my-first-set_1768308252_- 1.00g 0.19
</span><span>swap 512.00m
</span><span>var 12.00g
</span><span>var-snapset_my-first-set_1768308252_-var 1.20g 0.19
</span></code></pre>
<p>Note the 0.19% value in the <code>Data%</code> column: this is the percentage of the snapshot exception store that has been used so far. In this case it's a very healthy value. If the value begins to approach 100% you need to take action using <a href="https://man7.org/linux/man-pages/man8/lvresize.8.html"><code>lvresize(8)</code></a> or <code>snapm snapset resize</code> in order to avoid the snapshot being invalidated.</p>
<p>We will discuss more comprehensive monitoring and maintenance strategies in later blog updates. For now, you can use your regular storage administration tools (whether that is <a href="https://man7.org/linux/man-pages/man8/lvs.8.html"><code>lvs(8)</code></a> for LVM2 volumes, or the <a href="https://www.mankier.com/8/stratis"><code>stratis(8)</code></a> command for Stratis storage), or the <code>snapm snapshot list</code> command to keep an eye on the space available to your snapshots. You can resize individual snapshots using the corresponding tool (for example, <a href="https://man7.org/linux/man-pages/man8/lvresize.8.html"><code>lvresize(8)</code></a> for LVM2), or you can use the <code>snapm snapset resize</code> command to apply new size policies to an already created snapshot set.</p>
<h2 id="visualizing-changes">Visualizing Changes</h2>
<p>Before we conclude let's take a look at some of the advanced features in recent versions of <code>snapm</code>. For this part of the exercise, it helps if you can make some small change to the system. We will assume that your snapshot set included the root file system in this example but if that isn't the case you can adjust the paths used accordingly. We suggest creating a single new file — something simple made with the <code>echo</code> command is fine for our purposes:</p>
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span># echo &quot;Something changed!&quot; &gt; /etc/my-new-file.conf
</span></code></pre>
<p>Now that you have a definitive change in the file system state, use the <code>snapm snapset diff</code> command to view it:</p>
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span># snapm snapset diff my-first-set . -s /etc -i /etc/my-new-file.conf
</span><span>Gathering paths from my-first-set /etc: found 1879 paths
</span><span>Scanned 1879 paths in 0:00:00.784354 (excluded 0)
</span><span>Gathering paths from System Root /etc: found 1880 paths
</span><span>Scanned 1880 paths in 0:00:00.539372 (excluded 0)
</span><span>Found 7 differences in 0:00:00.012717
</span><span>Found 0 moves in 0:00:00.004574
</span><span>Saved 7 records to diffcache in 0:00:00.014500
</span><span>Built tree with 7 nodes
</span><span>/
</span><span>└── [*] etc
</span><span> └── [+] my-new-file.conf
</span></code></pre>
<p>Note that <code>my-new-file.conf</code> appears with the <code>[+]</code> annotation (in green if your terminal supports color output) indicating that it is a new file system entry added since <code>my-first-set</code> was created.</p>
<p>To see the exact change in the file content you can use the <code>-o/--output-format diff</code> option of the <code>snapm snapset diff</code> command:</p>
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span># snapm snapset diff my-first-set . -o diff -s /etc -i /etc/my-new-file.conf
</span><span>Loaded 1 records from diffcache in 0:00:00.000226
</span><span>Found 1 content differences
</span><span>diff a/etc/my-new-file.conf b/etc/my-new-file.conf
</span><span>new file mode 0o100644
</span><span>--- /dev/null
</span><span>+++ b/etc/my-new-file.conf 2026-01-20 16:59:42.257636
</span><span>@@ -0,0 +1 @@
</span><span>+Something changed!
</span></code></pre>
<p>There are two key details to notice here:</p>
<ul>
<li>The <code>-o diff</code> output is displayed in <em>unified diff</em> format (again with color coding if your terminal supports that)</li>
<li>The results appear quickly when the second command is run. This is because the differences from the first run are cached and reused.</li>
</ul>
<p>To see all the differences found between the snapshot set and the live system, remove the <code>-i /etc/my-new-file.conf</code> argument and run the command again:</p>
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span># snapm snapset diff my-first-set . -s /etc
</span><span>Gathering paths from my-first-set /etc: found 1879 paths
</span><span>Scanned 1879 paths in 0:00:00.662213 (excluded 0)
</span><span>Gathering paths from System Root /etc: found 1880 paths
</span><span>Scanned 1880 paths in 0:00:00.527266 (excluded 0)
</span><span>Found 7 differences in 0:00:00.012590
</span><span>Found 0 moves in 0:00:00.004542
</span><span>Saved 7 records to diffcache in 0:00:00.014054
</span><span>Built tree with 7 nodes
</span><span>/
</span><span>└── [*] etc
</span><span> ├── lvm
</span><span> │ ├── [*] archive
</span><span> │ │ ├── [-] fedora_00018-1908271671.vg
</span><span> │ │ └── [+] fedora_00028-486902226.vg
</span><span> │ └── [*] backup
</span><span> │ └── [*] fedora
</span><span> └── [+] my-new-file.conf
</span></code></pre>
<p>Note that in this example we see changes in the <code>/etc/lvm</code> directory: we are using LVM2 on this system and this is a natural consequence of LVM2's default metadata archival and backup settings. Do not be concerned if you see similar changes on your system when trying this out. In this example we also see that the cache is not used - this is because the new <code>snapset diff</code> command is using different options.</p>
<h2 id="conclusion">Conclusion</h2>
<p>That's it for now! We will look at more advanced uses of <code>snapm</code> and the full set of <em>Difference Engine</em> features in future blog posts. In the meantime check out the <code>snapm(8)</code> manual page and the <a href="https://snapm.readthedocs.io/en/latest/user_guide.html">User Guide</a> if this post whetted your appetite for more Snapshot Manager features!</p>
<p>If you would like to clean up and remove the snapshot set on your system, use the <code>snapm snapset delete</code> command:</p>
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span># snapm snapset delete my-first-set
</span></code></pre>
<section class="footnotes">
<ol class="footnotes-list">
<li id="fn-1">
<p>The snapshots making up a set are created sequentially, since there is presently no interface in Linux for creating multiple snapshots simultaneously. For this reason the individual snapshots will all have very slightly different timestamps. Snapshot Manager quantises these timestamps to provide a single unambiguous creation time for the set as a whole. <a href="#fr-1-1">↩</a></p>
</li>
<li id="fn-2">
<p>https://en.wikipedia.org/wiki/Universally_unique_identifier#Versions_3_and_5_(namespace_name-based) <a href="#fr-2-1">↩</a></p>
</li>
<li id="fn-3">
<p>Unless creating bootable snapshot sets, in which case autoactivate is always enabled and the set will start out in the <code>Active</code> state (We will cover bootable snapshot sets in detail in a future post). <a href="#fr-3-1">↩</a></p>
</li>
<li id="fn-4">
<p>https://github.com/snapshotmanager/snapm/issues/ <a href="#fr-4-1">↩</a></p>
</li>
<li id="fn-5">
<p>We are using the <code>lvs</code> program's <code>-o/--options</code> argument here to make sure the displayed fields fit on the page. By default you will see more columns in the tool output. <a href="#fr-5-1">↩</a></p>
</li>
</ol>
</section>
</content>
</entry>
<entry xml:lang="en">
<title>Getting snapm</title>
<published>2026-01-13T00:00:00+00:00</published>
<updated>2026-01-13T00:00:00+00:00</updated>
<author>
<name>
Unknown
</name>
</author>
<link rel="alternate" type="text/html" href="https://snapshotmanager.github.io/blog/getting-snapm/"/>
<id>https://snapshotmanager.github.io/blog/getting-snapm/</id>
<content type="html" xml:base="https://snapshotmanager.github.io/blog/getting-snapm/"><h1 id="getting-snapm">Getting <code>snapm</code></h1>
<p>Snapshot Manager is a Python application. It is simple to install whether you are working from distribution provided packages, or installing the latest source from git. For most users we recommend using distribution packages where available - you'll be able to take advantage of automatic updates and simplified configuration, but read on to discover how to install <code>snapm</code> using various methods, and where to obtain the Python packages and source code if required.</p>
<h2 id="1-installing-distribution-packages-with-dnf-recommended-for-most-users">1. Installing distribution packages with <code>dnf</code> (recommended for most users).</h2>
<p>What you'll need:</p>
<ul>
<li>
<p>A Linux system installed with a recent edition of <a href="https://fedoraproject.org">Fedora</a> (F42+), <a href="https://www.centos.org/download/">CentOS Stream</a> (c9s+), or <a href="https://developers.redhat.com/products/rhel/download">Red Hat Enterprise Linux</a> (RHEL9.6 onward).</p>
</li>
<li>
<p>Administrative privileges (or membership of the wheel group).</p>
</li>
<li>
<p>A working internet connection.</p>
</li>
</ul>
<p>Using the native dnf package management tool, open a terminal and either switch to the root account by running <code>su -</code> (if you have a root account password configured), or prefix the <code>dnf install</code> command with <code>sudo</code>, give the appropriate password when prompted, and <code>dnf</code> will do its thing, pull the packages down and get them installed:</p>
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span>$ su -
</span><span>Password:
</span><span># dnf -y install snapm
</span></code></pre>
<p>Or:</p>
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span>$ sudo dnf -y install snapm
</span><span>[sudo] password for bmr:
</span></code></pre>
<p>For example, on Fedora 42 with <code>snapm-0.7.0-1.fc42</code> the installation will look something like this:</p>
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span># dnf -y install snapm
</span><span>Updating and loading repositories:
</span><span>Repositories loaded.
</span><span>Package Arch Version Repository Size
</span><span>Installing:
</span><span> snapm noarch 0.7.0-1.fc42 updates 38.0 KiB
</span><span>Installing dependencies:
</span><span> python3-snapm noarch 0.7.0-1.fc42 updates 1.6 MiB
</span><span>Installing weak dependencies:
</span><span> boom-boot noarch 1.6.8-2.fc42 updates 30.3 KiB
</span><span>
</span><span>Transaction Summary:
</span><span> Installing: 3 packages
</span><span>
</span><span>Total size of inbound packages is 475 KiB. Need to download 475 KiB.
</span><span>After this operation, 2 MiB extra will be used (install 2 MiB, remove 0 B).
</span><span>[1/3] snapm-0:0.7.0-1.fc42.noarch 100% | 395.7 KiB/s | 36.8 KiB | 00m00s
</span><span>[2/3] boom-boot-0:1.6.8-2.fc42.noarch 100% | 245.4 KiB/s | 29.5 KiB | 00m00s
</span><span>[3/3] python3-snapm-0:0.7.0-1.fc42.noar 100% | 2.0 MiB/s | 408.8 KiB | 00m00s
</span><span>--------------------------------------------------------------------------------
</span><span>[3/3] Total 100% | 1.3 MiB/s | 475.0 KiB | 00m00s
</span><span>Running transaction
</span><span>[1/5] Verify package files 100% | 250.0 B/s | 3.0 B | 00m00s
</span><span>[2/5] Prepare transaction 100% | 21.0 B/s | 3.0 B | 00m00s
</span><span>[3/5] Installing python3-snapm-0:0.7.0- 100% | 20.7 MiB/s | 1.7 MiB | 00m00s
</span><span>[4/5] Installing snapm-0:0.7.0-1.fc42.n 100% | 542.2 KiB/s | 41.2 KiB | 00m00s
</span><span>[5/5] Installing boom-boot-0:1.6.8-2.fc 100% | 33.1 KiB/s | 31.4 KiB | 00m01s
</span><span>Complete!
</span></code></pre>
<p>Note that the <code>boom-boot</code> package (containing the boom boot manager CLI) is a weak dependency of <code>snapm</code> - that is to say, it is recommended but not required (the <code>python3-snapm</code> package separately depends on the <code>python3-boom</code> package that provides the procedural API that <code>snapm</code> uses). If you're installing <code>snapm</code> for manual use (rather than automation using the API or Ansible roles) you probably want to have <code>boom</code> installed too - it is the easiest way to get deeper insight into your snapshot boot entries.</p>
<p>If you would like to also have the HTML documentation available to browse locally add the <code>python3-snapm-doc</code> package name to your <code>dnf install</code> invocation.</p>
<h2 id="2-installing-copr-builds-from-github-early-access-to-new-features-fixes">2. Installing copr builds from GitHub (early access to new features &amp; fixes)</h2>
<p>What you'll need:</p>
<ul>
<li>
<p>The URL or PR# of the pull request that you want to install a build from.</p>
</li>
<li>
<p>A Linux system installed with a recent edition of <a href="https://fedoraproject.org">Fedora</a> (F42+), <a href="https://www.centos.org/download/">CentOS Stream</a> (c9s+), or <a href="https://developers.redhat.com/products/rhel/download">Red Hat Enterprise Linux</a> (RHEL9.6 onward).</p>
</li>
<li>
<p>The package <code>python3-dnf-plugins-core</code> installed for the DNF copr plugin.</p>
</li>
<li>
<p>Administrative privileges (or membership of the wheel group).</p>
</li>
<li>
<p>A working internet connection.</p>
</li>
</ul>
<p>In this scenario, we'll be using the DNF support for copr repositories in the core plug-ins package to enable a pull request repository and install the packages.</p>
<p>Either open the pull request web page, locate the comment from the Packit build system, and copy the provided <code>dnf</code> command for your distribution, or construct the repository argument for the dnf copr enable command as follows: ‘packit/snapshotmanager-snapm-PR#’, where PR# is the pull request number assigned by GitHub in the <a href="https://github.com/snapshotmanager/snapm/">snapshotmanager/snapm</a> repository.</p>
<p>The command will end up looking like this:</p>
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span># dnf copr enable packit/snapshotmanager-snapm-830
</span><span>https://copr.fedorainfracloud.org/api_ 100% | 696.0 B/s | 485.0 B | 00m01s
</span><span>Enabling a Copr repository. Please note that this repository is not part
</span><span>of the main distribution, and quality may vary.
</span><span>
</span><span>The Fedora Project does not exercise any power over the contents of
</span><span>this repository beyond the rules outlined in the Copr FAQ at
</span><span>&lt;https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-in-copr&gt;,
</span><span>and packages are not held to any quality or security level.
</span><span>
</span><span>Please do not file bug reports about these packages in Fedora
</span><span>Bugzilla. In case of problems, contact the owner of this repository.
</span><span>Is this ok [y/N]: y
</span></code></pre>
<p>Enter ‘y’ when prompted to confirm enabling the repository then follow the instructions from <a href="https://snapshotmanager.github.io/blog/getting-snapm/#1-installing-distribution-packages-with-dnf-recommended-for-most-users">1.</a> to install the packages. When first installing packages from a new copr repository, you will be prompted to accept the Open PGP key used for signing packages in that repository: decide whether you trust the publisher of the builds, and enter ‘y’ to accept if so.</p>
<p>Note that the <code>copr</code> builds produced by the Packit build system are transient: they are retained for 60 days, after which the package repositories are permanently deleted. This should not be a problem in most cases as the builds are intended to be used for short term testing and feedback on active development.</p>
<h2 id="3-installing-from-pypi-bleeding-edge-releases-some-assembly-required">3. Installing from PyPi (Bleeding Edge Releases: Some Assembly Required)</h2>
<ul>
<li>
<p>A Linux system installed with a recent edition of <a href="https://fedoraproject.org">Fedora</a> (F42+), <a href="https://www.centos.org/download/">CentOS Stream</a> (c9s+), or <a href="https://developers.redhat.com/products/rhel/download">Red Hat Enterprise Linux</a> (RHEL9.6 onward).</p>
</li>
<li>
<p>The package <code>python3-pip</code> installed for the pip program.</p>
</li>
<li>
<p>Administrative privileges (or membership of the wheel group).</p>
</li>
<li>
<p>A working internet connection.</p>
</li>
</ul>
<p>New releases of <code>snapm</code> are pushed to the public PyPi repository at <a href="https://pypi.org/project/snapm/">snapm</a>. Often these will be available before updates to distribution packages are published (particularly for <a href="https://www.centos.org/download/">CentOS Stream</a> and <a href="https://developers.redhat.com/products/rhel/download">Red Hat Enterprise Linux</a>). These are mostly provided for users wanting to consume bleeding-edge releases in CI environments and are not typically recommended for end-users. You can install the latest code from PyPi using the <code>pip</code> command, including in a Python virtual environment.</p>
<p>To install the latest package available (after activating any <code>venv</code>, if you wish to use one):</p>
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span>$ [sudo] pip install snapm
</span></code></pre>
<p>You can install <code>snapm</code> as a regular user or system wide, but be aware of the consequences of running pip as the root user if opting for the latter: consult your distribution's Python packaging documentation for further information. The <code>snapm</code> command requires administrative privileges for all snapshot management operations (but you can view the builtin help text as any user).</p>
<p>Just bear in mind: the Python packages do not currently include the configuration, systemd units, or manual pages that are included in the source and RPM distributions. This is a result of changes in the Python packaging ecosystem and the deprecation of <code>data_files</code> support in Python <code>setuptools</code>. You can reuse previously installed configuration files and resources to some extent but these may be out-of-date compared to the installation you are getting from PyPi. You will need to make any corrections or adjustments yourself. The easiest way to get these missing pieces is to clone the <a href="https://github.com/snapshotmanager/snapm/">source repository</a> and copy the files to their proper locations with the following commands:</p>
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span>$ sudo mkdir -p /etc/snapm/plugins.d /etc/snapm/schedule.d
</span><span>$ sudo cp systemd/*.timer /usr/lib/systemd/system
</span><span>$ sudo cp systemd/*.service /usr/lib/systemd/system
</span><span>$ sudo cp systemd/tmpfiles.d/snapm.conf /usr/lib/tmpfiles.d
</span><span>$ sudo systemd-tmpfiles –create /usr/lib/tmpfiles.d/snapm.conf
</span><span>$ sudo systemctl daemon-reload
</span></code></pre>
<p>If you would also like to install the latest manual pages, copy them from the man/ directory in the source tree into the appropriate location for your distribution (normally <code>/usr/share/man/man{5,8}</code>).</p>
<h2 id="4-installing-or-running-from-source-for-experts-contributors">4. Installing or Running From Source (For Experts &amp; Contributors)</h2>
<ul>
<li>
<p>A Linux system installed with a recent edition of <a href="https://fedoraproject.org">Fedora</a> (F42+), <a href="https://www.centos.org/download/">CentOS Stream</a> (c9s+), or <a href="https://developers.redhat.com/products/rhel/download">Red Hat Enterprise Linux</a> (RHEL9.6 onward).</p>
</li>
<li>
<p>A working installation of the <code>git</code> version control system.</p>
</li>
<li>
<p>(Optionally) the package <code>python3-pip</code> installed for the pip program.</p>
</li>
<li>
<p>Administrative privileges (or membership of the wheel group).</p>
</li>
<li>
<p>A working internet connection.</p>
</li>
</ul>
<p>First clone the <code>snapm</code> repository from GitHub with the command:</p>
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span>$ git clone https://github.com/snapshotmanager/snapm
</span></code></pre>
<p>Optionally, also clone the boom-boot repository into the same parent directory (this is useful if you want to test or work on features or fixes that span both <code>snapm</code> and boom):</p>
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span>$ git clone https://github.com/snapshotmanager/boom-boot
</span></code></pre>
<p>To run <code>snapm</code> from the source tree, gain root privileges, change to the directory where you cloned the source (normally <code>snapm/</code>, relative to the directory where git-clone ran), and run the command:</p>
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span># . scripts/setpaths.sh
</span></code></pre>
<p>This will set the <code>PATH</code> and <code>PYTHONPATH</code> environment variables appropriately for you to run <code>snapm</code> from the checked-out sources. It will also enable support for using the checked out copy of <code>boom-boot</code> if you also cloned that (assuming it is found at the path <code>../boom-boot</code> relative to the <code>snapm/</code> directory).</p>
<p>You can now run the <code>snapm</code> and boom commands using the latest source from <code>git</code>. Every time you pull or checkout a new revision subsequent invocations will use that copy of the code.</p>
<p>To install the current revision in a git clone, run:</p>
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span>$ sudo pip install .
</span></code></pre>
<p>Just remember that all the caveats from <a href="https://snapshotmanager.github.io/blog/getting-snapm/#3-installing-from-pypi-bleeding-edge-releases-some-assembly-required">3.</a> apply to git clones too: you are responsible for ensuring all configuration files are in place, and for keeping them up-to-date with any code changes.</p>
<h2 id="5-what-s-in-the-box">5. What's in the Box?</h2>
<p>Depending on how <code>snapm</code> was installed the package will include some or all of the components needed to run and learn about the tool. This varies according to the packaging format (or lack thereof, in the case of source installations).</p>
<h3 id="5-1-source-distribution">5.1 Source Distribution</h3>
<p>The source distribution (a git checkout or a tarball) includes all the source and in tree documentation for Snapshot Manager but you are responsible for installing it and making it usable on your system. Refer to <a href="https://snapshotmanager.github.io/blog/getting-snapm/#3-installing-from-pypi-bleeding-edge-releases-some-assembly-required">3.</a> for instructions.</p>
<h3 id="5-2-rpm-packages">5.2 RPM Packages</h3>
<p>The <code>snapm</code> project is packaged for RPM based distributions as three subpackages that all build from the same source RPM:</p>
<ul>
<li>
<p><code>snapm</code> — The <code>snapm(8)</code> program, its manual pages, configuration files, systemd units, <code>tmpfiles.d</code> configuration, and <a href="https://github.com/snapshotmanager/snapm/blob/main/README.md"><code>README.md</code></a>.</p>
</li>
<li>
<p><code>python3-snapm</code> — The Python API comprising the <code>snapm</code> Python package.</p>
</li>
<li>
<p><code>python3-snapm-doc</code> — HTML user and API documentation, normally found in <code>/usr/share/doc/python3-snapm-doc</code>.</p>
</li>
</ul>
<p>You can browse the documentation installed on your system by running the following command (assuming you have a working web browser in a reasonably modern desktop environment):</p>
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span>$ xdg-open /usr/share/doc/python3-snapm-doc/doc/html/index.html
</span></code></pre>
<p>Or by visiting <a href="file:///usr/share/doc/python3-snapm-doc/doc/html/index.html">this URL</a>.</p>
<h3 id="5-3-pypi-packages">5.3 PyPi Packages</h3>
<p>The PyPi (pip) packages include only the executable code that makes up Snapshot Manager. You will need to configure the program yourself and install any documentation you wish to use, following the directions in section <a href="https://snapshotmanager.github.io/blog/getting-snapm/#3-installing-from-pypi-bleeding-edge-releases-some-assembly-required">3.</a>.</p>
</content>
</entry>
<entry xml:lang="en">
<title>snapm 0.7.0 Release Notes</title>
<published>2026-01-06T00:00:00+00:00</published>
<updated>2026-01-06T00:00:00+00:00</updated>
<author>
<name>
Unknown
</name>
</author>
<link rel="alternate" type="text/html" href="https://snapshotmanager.github.io/blog/snapm-release-notes-0-7-0/"/>
<id>https://snapshotmanager.github.io/blog/snapm-release-notes-0-7-0/</id>
<content type="html" xml:base="https://snapshotmanager.github.io/blog/snapm-release-notes-0-7-0/"><h1 id="overview">Overview</h1>
<p>This release introduces significant new features, fixes, and quality of life improvements. These include enhancements to the <a href="https://snapm.readthedocs.io/en/latest/user_guide.html#difference-engine">Difference Engine</a>: support for multiple <code>-s|--start-path</code> arguments, cache fixes, better file type detection when not using <code>--file-types</code>, and improved move detection behaviour when multiple destinations exist, as well as support for plugin priorities in <code>Manager</code> and the in-tree plugins (for example, allowing the administrator to choose between <code>lvm2-thin</code>, and <code>lvm2-cow</code> snapshot providers where both can snapshot the same volume), better documentation for the Mount Manager in the <a href="https://snapm.readthedocs.io/en/latest/user_guide.html"><em>User Guide</em></a>, and a new, user-visible timeline categorization ("yearly", "monthly", "weekly", "daily", etc.) that is available for all snapshot sets. This release also includes a fix for the <code>snapm</code> / <code>podman</code> netns mount issue <a href="https://github.com/snapshotmanager/snapm/wiki/Known-issue:-snapm-snapset-%7Bmount,umount%7D-and-podman-netfs-mounts">documented</a> in earlier releases (<a href="https://github.com/snapshotmanager/snapm/issues/586">#586</a>) and stronger validation for <code>schedule create</code> name arguments (<a href="https://github.com/snapshotmanager/snapm/issues/906">#906</a>).</p>
<p>Users should upgrade to <a href="https://github.com/snapshotmanager/snapm/releases/tag/v0.7.0">v0.7.0</a> as soon as possible to take advantage of these enhancements.</p>
<h2 id="notes">Notes</h2>
<ul>
<li>It is now possible to specify the <code>-s|--start</code> path multiple times when invoking the <code>snapset diff</code> and <code>snapset diffreport</code> commands. This allows the user to compare multiple independent subtrees in a single <code>diff</code> operation.</li>
<li>The path based file type detection has been improved to support more common file extensions, text and binary path locations, and categorisations.</li>
<li>A new <code>BINARY_LOG</code> file type categorisation has been added to describe files such as <code>wtmp</code>, SAR logs, and the journal.</li>
<li>Plugins now support a <code>PluginPriority</code> configuration that specifies a positive integer priority level. The plugin with the greatest priority is chosen when multiple plugins can snapshot the same device. This allows the user to prefer <code>lvm2-cow</code> snapshots over <code>lvm2-thin</code> where both are possible and will in future allow support for file system level snapshots (for example, Btrfs). Refer to <code>snapm(8)</code>, and <code>snapm-plugins.d(5)</code> for further information on configuring plugin priorities.</li>
<li>The Mount Manager is now described in the on-line and in-package <a href="https://snapm.readthedocs.io/en/latest/user_guide.html"><em>User Guide</em></a>.</li>
<li>The Mount Manager now handles unmounting of duplicate <code>/run/netns</code> mounts via a targeted workaround.</li>
<li>The timeline classification algorithm used by the <code>Timeline</code> garbage collection policy has been generalised and is now available for all snapshot sets via the "Categories" snapshot set property and "categories" report field.</li>
<li>The static file type classifier now uses a broader set of rules for classifying likely text or binary content types.</li>
<li>The <code>tree</code> output format of the <code>snapset diff</code> command now displays separate nodes for paths that have both been moved and modified (for example, a file that was backed up and then changed in-place).</li>
</ul>
<h2 id="what-s-changed">What's Changed</h2>
<ul>
<li>doc: add new snapm logo to README.md by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in <a href="https://github.com/snapshotmanager/snapm/pull/823">#823</a></li>
<li>doc: update <code>README.md</code> and <code>user_guide.rst</code> with mount manager and difference engine by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in <a href="https://github.com/snapshotmanager/snapm/pull/830">#830</a></li>
<li>snapm: btrfs plugin pre-requisite features and fixes by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in <a href="https://github.com/snapshotmanager/snapm/pull/843">#843</a></li>
<li>Fixes for progress log interleaving and text-like best-guess file type detection by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in <a href="https://github.com/snapshotmanager/snapm/pull/851">#851</a></li>
<li>fsdiff: add <code>BINARY_LOG</code> file type category and fix <code>TEXT_FILE_PATHS</code> prefixing by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in <a href="https://github.com/snapshotmanager/snapm/pull/855">#855</a></li>
<li>fsdiff: ctrl char glitches when diff -o tree --color=always | less -R by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in <a href="https://github.com/snapshotmanager/snapm/pull/857">#857</a></li>
<li>fsdiff: tolerate missing <code>python-file-magic</code> and work around <code>Magic.close()</code> bug by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in <a href="https://github.com/snapshotmanager/snapm/pull/859">#859</a></li>
<li>fsdiff: make <code>include_system_dirs</code> more robust and disable in next release by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in <a href="https://github.com/snapshotmanager/snapm/pull/871">#871</a></li>
<li>fsdiff: implement cheap sibbling proximity heuristic for moves by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in <a href="https://github.com/snapshotmanager/snapm/pull/874">#874</a></li>
<li>fsdiff: support <code>DiffOptions.from_path</code> as list by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in <a href="https://github.com/snapshotmanager/snapm/pull/875">#875</a>)</li>
<li>plugins: bump plugin versions for prio support by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in <a href="https://github.com/snapshotmanager/snapm/pull/876">#876</a></li>
<li>tests: improve <code>snapm.fsdiff</code> coverage by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in <a href="https://github.com/snapshotmanager/snapm/pull/881">#991</a></li>
<li>snapm: lift timeline classification logic up to <code>SnapshotSet</code> by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in <a href="https://github.com/snapshotmanager/snapm/pull/885">#885</a></li>
<li>snapm: don't alpha sort categories in reports by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in <a href="https://github.com/snapshotmanager/snapm/pull/892">#892</a></li>
<li>mounts: container mount workarounds by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in <a href="https://github.com/snapshotmanager/snapm/pull/900">#900</a></li>
<li>snapm: schedule name checks by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in <a href="https://github.com/snapshotmanager/snapm/pull/910">#910</a></li>
<li>fsdiff: add <code>DiffOptions.no_mem_check</code> / <code>--no-mem-check</code> option by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in <a href="https://github.com/snapshotmanager/snapm/pull/912">#912</a></li>
<li>snapm: broaden file type heuristics for suffix paths and support multiple change records in tree rendering by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in <a href="https://github.com/snapshotmanager/snapm/pull/913">#913</a></li>
</ul>
<p><strong>Full Changelog</strong>: <a href="https://github.com/snapshotmanager/snapm/compare/v0.6.0...v0.7.0">v0.6.0..v0.7.0</a></p>
</content>
</entry>
<entry xml:lang="en">
<title>snapm 0.5.3 Release Notes</title>
<published>2026-01-05T00:00:00+00:00</published>
<updated>2026-01-05T00:00:00+00:00</updated>
<author>
<name>
Unknown
</name>
</author>
<link rel="alternate" type="text/html" href="https://snapshotmanager.github.io/blog/snapm-release-notes-0-5-3/"/>
<id>https://snapshotmanager.github.io/blog/snapm-release-notes-0-5-3/</id>
<content type="html" xml:base="https://snapshotmanager.github.io/blog/snapm-release-notes-0-5-3/"><h1 id="overview">Overview</h1>
<p>This is a maintenance release for <a href="https://github.com/snapshotmanager/snapm/tree/snapm-0.5-stable">snapm-0.5-stable</a> that includes two bug fixes.</p>
<p>Users of snapm-0.5.x who are unable to upgrade to a later y-stream release
should update to
<a href="https://github.com/snapshotmanager/snapm/releases/tag/v0.5.3">v0.5.3</a> as soon
as possible to take advantage of these fixes.</p>
<h2 id="what-s-changed">What's Changed</h2>
<ul>
<li>Timeline index fix for v0.5.2 by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in
<a href="https://github.com/snapshotmanager/snapm/pull/609">#609</a></li>
<li>boot: hex escape literal ':' in values passed to systemd.{mount,swap}-extra
by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in <a href="https://github.com/snapshotmanager/snapm/pull/894">#894</a></li>
</ul>
<p><strong>Full Changelog</strong>: <a href="https://github.com/snapshotmanager/snapm/compare/v0.5.2...v0.5.3">v0.5.2..v0.5.3</a></p>
</content>
</entry>
<entry xml:lang="en">
<title>snapm 0.6.0 Release Notes</title>
<published>2025-12-22T00:00:00+00:00</published>
<updated>2025-12-22T00:00:00+00:00</updated>
<author>
<name>
Unknown
</name>
</author>
<link rel="alternate" type="text/html" href="https://snapshotmanager.github.io/blog/snapm-release-notes-0-6-0/"/>
<id>https://snapshotmanager.github.io/blog/snapm-release-notes-0-6-0/</id>
<content type="html" xml:base="https://snapshotmanager.github.io/blog/snapm-release-notes-0-6-0/"><h1 id="overview">Overview</h1>
<p>This release introduces significant new features and fixes, including the
<a href="https://github.com/snapshotmanager/snapm/pull/541">Mount Manager</a> and the
<a href="https://snapm.readthedocs.io/en/latest/user_guide.html#difference-engine">Difference
Engine</a>
for efficiently computing changes between two snapshot sets, or the system root
file system and a snapshot set. Fixes include Stratis plugin performance
enhancements and bug fixes for lvm2 device callouts.</p>
<p>Users should upgrade to
<a href="https://github.com/snapshotmanager/snapm/releases/tag/v0.6.0">v0.6.0</a> as soon
as possible to take advantage of these enhancements.</p>
<h2 id="notes">Notes</h2>
<ul>
<li>It is now possible to mount individual snapshot sets and interact with them
using the <code>snapset {mount,umount}</code>, <code>snapset exec</code>, and <code>snapset shell</code>
commands. Snapshot sets are mounted under <code>/run/snapm/mounts</code>.</li>
<li>Comprehensive file system comparison is now available with the <code>snapset diff</code>
and <code>snapset diffreport</code> commands. See <code>snapm(8)</code> and the <a href="https://snapm.readthedocs.io/en/latest/user_guide.html#difference-engine">user
guide</a>
for more information.</li>
<li>The <code>snapm.fsdiff</code> API is considered unstable and may be subject to change in
a future release.</li>
<li>The <code>snapset diff</code> <code>--output-format=json</code> JSON schema is also potentially
subject to change and will be formalised in a future release.</li>
<li>The <code>snapset diff</code>/<code>snapset diffreport</code> command syntax is stable but output
and formatting may change in future releases.</li>
<li>Future releases may include new content differs for specific file types and
more comprehensive file type detection when libmagic is disabled.</li>
<li>Generating content diffs of large file system trees with many content changes
may consume large amounts of memory: <code>snapm</code> will refuse to diff trees if
<code>VmRSS</code> exceeds 33% of system memory after walking the filesystem. Caching is
disabled if <code>VmRSS</code> exceeds 60% of system memory after computing diffs.</li>
</ul>
<h2 id="what-s-changed">What's Changed</h2>
<ul>
<li>lvm2: Fix "no device" case for _is_lvm_device() and avoid no provider test if
/boot is not a mount point by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in
<a href="https://github.com/snapshotmanager/snapm/pull/589">#589</a></li>
<li>Add mount manager by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in
<a href="https://github.com/snapshotmanager/snapm/pull/541">#541</a></li>
<li>snapm: fix renaming of snapshot sets with boot entries by
<a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in
<a href="https://github.com/snapshotmanager/snapm/pull/591">#591</a></li>
<li>schedule: fix timeline garbage collection by
<a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in
<a href="https://github.com/snapshotmanager/snapm/pull/596">#596</a></li>
<li>schedule: fix TIMELINE policy retention indexing when <code>keep_x &gt; len(x)</code> by
<a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in
<a href="https://github.com/snapshotmanager/snapm/pull/607">#607</a></li>
<li>stratis: re-use initial DBus query for StratisSnapshot cache by
<a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in
<a href="https://github.com/snapshotmanager/snapm/pull/615">#615</a></li>
<li>container_tests: fix GcPolicyParamsTimeline.evaluate() tests edge case by
<a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in
<a href="https://github.com/snapshotmanager/snapm/pull/628">#628</a></li>
<li>Clean up and enhance progress implementation by
<a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in
<a href="https://github.com/snapshotmanager/snapm/pull/646">#646</a></li>
<li>doc: add missing snapm.manager._mounts to Sphinx docs by
<a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in
<a href="https://github.com/snapshotmanager/snapm/pull/661">#661</a></li>
<li>Fix progress message overflow, bar width, and BrokenPipeError handling by
<a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in
<a href="https://github.com/snapshotmanager/snapm/pull/662">#662</a></li>
<li>progress: clean up Progress and add Throbber classes by
<a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in
<a href="https://github.com/snapshotmanager/snapm/pull/675">#675</a></li>
<li>progress: Fix <code>Throbber</code> <code>no_clear</code> bug and add styles by
<a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in
<a href="https://github.com/snapshotmanager/snapm/pull/679">#679</a></li>
<li>mounts: fix incorrect SnapshotSet instead of name in name_map by
<a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in
<a href="https://github.com/snapshotmanager/snapm/pull/684">#684</a></li>
<li>snapm: add fsdiff snapshot set comparison facility by
<a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in
<a href="https://github.com/snapshotmanager/snapm/pull/620">#620</a></li>
<li>progress: cleanups and log integration by
<a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in
<a href="https://github.com/snapshotmanager/snapm/pull/698">#698</a></li>
<li>snapm: implement snapshot set comparison UI (snapm snapset diff) by
<a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in
<a href="https://github.com/snapshotmanager/snapm/pull/707">#707</a></li>
<li>snapm: address v0.6.0 feature/fix release blockers by
<a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in
<a href="https://github.com/snapshotmanager/snapm/pull/759">#759</a></li>
<li>snapm: fix "Computing diffs" progress bar flicker and at move detector
progress by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in
<a href="https://github.com/snapshotmanager/snapm/pull/775">#775</a></li>
<li>doc: add missing links, summary format and clarify defaults for output
formats by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in
<a href="https://github.com/snapshotmanager/snapm/pull/779">#779</a></li>
<li>fsdiff: catch EOFError on truncated cache file by
<a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in
<a href="https://github.com/snapshotmanager/snapm/pull/782">#782</a></li>
<li>fsdiff: move detector may mis-detect identical files as moves by
<a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in
<a href="https://github.com/snapshotmanager/snapm/pull/784">#784</a></li>
<li>fsdiff: optimize cache writing and add progress reporting by
<a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in
<a href="https://github.com/snapshotmanager/snapm/pull/791">#791</a></li>
<li>fsdiff: implement best-effort file type detection and "always exclude" paths
by <a href="https://github.com/bmr-cymru/">@bmr-cymru</a> in
<a href="https://github.com/snapshotmanager/snapm/pull/810">#810</a></li>
</ul>
<h2 id="known-issues">Known issues</h2>
<p>There is one known issue for this release. Please see the wiki pages for more
details, status, and workarounds:</p>
<ul>
<li><a href="https://github.com/snapshotmanager/snapm/wiki/Known-issue:-snapm-snapset-%7Bmount,umount%7D-and-podman-netfs-mounts">snapm snapset {mount,umount} and podman netfs mounts</a></li>
</ul>
<p>This will be addressed in a future release.</p>
<p><strong>Full Changelog</strong>: <a href="https://github.com/snapshotmanager/snapm/compare/v0.5.2...v0.6.0">v0.5.2...v0.6.0</a></p>
</content>
</entry>
<entry xml:lang="en">
<title>Snapshot Manager how-to/walkthrough</title>
<published>2025-12-22T00:00:00+00:00</published>
<updated>2025-12-22T00:00:00+00:00</updated>
<author>
<name>
Unknown
</name>
</author>
<link rel="alternate" type="text/html" href="https://snapshotmanager.github.io/howto/"/>
<id>https://snapshotmanager.github.io/howto/</id>
<content type="html" xml:base="https://snapshotmanager.github.io/howto/"><p>User Guide</p>
<p>This guide provides user documentation for the snapshot manager (snapm) tool.</p>
<p>Overview</p>
<p>Snapshot manager (snapm) is a tool for managing coordinated sets of snapshots on Linux systems. The snapm tool allows snapshots of multiple volumes to be captured at the same time, representing the system state at the time the snapshot set was created. The tool has a modular plugin architecture allowing different snapshot backends to be used together. Currently snapshots using LVM2 copy-on-write as well as thinly provisioned snapshots using both LVM2 and Stratis are supported.</p>
<p>Key Concepts</p>
<h3 id="snapshot-sets">Snapshot Sets</h3>
<p>Snapshot manager groups snapshots taken at the same moment in time into a named "snapshot set", or snapset. This allows the snapshots to be managed as a single unit and simplifies the management of snapshots of multiple volumes. Each snapshot set must contain at least one snapshot.</p>
<h3 id="size-policies">Size Policies</h3>
<p>Size policies control the size of fixed-sized snapshots and check for available space when creating a snapshot set. Some snapshot implementations (Lvm2CoW) require a fixed size to be specified for the snapshot backstore when the snapshot is created. The default size allocated by snapshot manager is 2x the current file system usage, allowing the existing content of the volume to be overwritten twice before exhausting the snapshot space. Plugins for snapshot providers that do not require a fixed snapshot size will check that space is available for the requested size policy at snapshot set creation time.</p>
<p>Available size policies:</p>
<ul>
<li><strong>FIXED</strong> - a fixed size given on the command line</li>
<li><strong>FREE</strong> - a percentage fraction of the free space available</li>
<li><strong>USED</strong> - a percentage fraction of the space currently used on the mount point (may be greater than 100%)</li>
<li><strong>SIZE</strong> - a percentage fraction of the origin device size from 0 to 100%</li>
</ul>
<p>The FIXED size policy accepts optional units of KiB, MiB, GiB, TiB, PiB, EiB and ZiB. Units may be abbreviated to the first character.</p>
<p>The USED size policy can only be applied to mounted file systems.</p>
<p>Difference Engine</p>
<p>The Difference Engine is a core facility in <code>snapm</code> that allows for detailed comparisons between two snapshot sets, or between a snapshot set and the currently running system.</p>
<p>How it Works</p>
<p>The engine operates by recursively walking the file system trees of both the source and target. It performs a multi-stage analysis to identify changes:</p>
<ul>
<li></li>
</ul>
<p><strong>Entry Detection</strong>: Identifies files, directories, and symlinks that have been added, removed, or modified.</p>
<ul>
<li></li>
</ul>
<p><strong>Move Detection</strong>: By matching content hashes, the engine can identify files that have been renamed or moved between directories rather than simply being deleted and recreated.</p>
<ul>
<li></li>
</ul>
<p><strong>Metadata Analysis</strong>: Detects changes in file permissions (mode), ownership (UID/GID), and extended attributes (xattrs).</p>
<ul>
<li></li>
</ul>
<p><strong>Content Comparison</strong>: Performs deep content comparisons for regular files, including generating standard unified diffs for text files.</p>
<p>Output Formats and Use Cases</p>
<p>The Difference Engine supports several output formats via the <code>snapset diff</code> <code>--output-format</code> argument, each suited to different tasks:</p>
<ul>
<li></li>
</ul>
<p><strong>paths</strong>: Useful for scripting, allowing you to pipe a list of changed files to other tools like <code>tar</code> or <code>rsync</code>.</p>
<ul>
<li></li>
</ul>
<p><strong>full</strong>: Provides a detailed report including old and new file attributes (permissions, ownership, size, modification time) for every change.</p>
<ul>
<li></li>
</ul>
<p><strong>short</strong>: A concise summary listing the change status code and path for each modified file.</p>
<ul>
<li></li>
</ul>
<p><strong>json</strong>: Outputs the complete difference data as a JSON object, suitable for parsing by external tools and automation scripts.</p>
<ul>
<li></li>
</ul>
<p><strong>diff</strong>: Generates a standard unified diff of content changes for modified files. This format is useful for generating patches or detailed content review.</p>
<ul>
<li></li>
</ul>
<p><strong>summary</strong>: Brief summary of the count of different change types. Change types are colorized using the same coding as <code>tree</code> output.</p>
<ul>
<li></li>
</ul>
<p><strong>tree</strong>: (Default) Displays changes in a hierarchical tree structure, similar to the standard <code>tree</code> command but annotated with change status.</p>
<p>In addition differences can be reported in a tabular format using the standard <code>snapm</code> reporting mechanism using the <code>snapset diffreport</code> command. The available <code>diffreport</code> report output fields are:</p>
<ul>
<li><strong>path</strong>: Difference path (string)</li>
<li><strong>type</strong>: Difference type (string)</li>
<li><strong>size_delta</strong>: Diff size change (size)</li>
<li><strong>content</strong>: Content changed (string)</li>
<li><strong>metadata</strong>: Metadata changed (string)</li>
<li><strong>mode_old</strong>: Old path mode (string)</li>
<li><strong>mode_new</strong>: New path mode (string)</li>
<li><strong>category</strong>: File category (string)</li>
<li><strong>movedfrom</strong>: Move source (string)</li>
<li><strong>movedto</strong>: Move destination (string)</li>
<li><strong>diffsummary</strong>: Summary of content differences (string)</li>
<li><strong>hash_old</strong>: Old file content hash (string)</li>
<li><strong>hash_new</strong>: New file content hash (string)</li>
<li><strong>filetype</strong>: File type (string)</li>
<li><strong>mtime_old</strong>: Old modification time (time)</li>
<li><strong>mtime_new</strong>: New modification time (time)</li>
</ul>
<h3 id="comparison-modes">Comparison Modes</h3>
<p>You can fine-tune the comparison using various flags:</p>
<ul>
<li></li>
</ul>
<p><strong>Content-Only</strong> (<code>-c</code>): Ignores all metadata changes and only reports files where the actual data has changed.</p>
<ul>
<li></li>
</ul>
<p><strong>Ignore Options</strong>: Use <code>--ignore-timestamps</code>, <code>--ignore-permissions</code>, or <code>--ignore-ownership</code> to filter out "noise" during comparisons.</p>
<p>Performance and the Diff Cache</p>
<p>Walking large file systems and computing content hashes can be resource-intensive. To improve performance, <code>snapm</code> implements a <strong>diffcache</strong>.</p>
<ul>
<li></li>
</ul>
<p><strong>How it works</strong>: When a comparison is performed, the results are compressed and stored in <code>/var/cache/snapm/diffcache</code>.</p>
<ul>
<li></li>
</ul>
<p><strong>Cache Reuse</strong>: Subsequent <code>diff</code> or <code>diffreport</code> commands between the same two sets will load the results from the cache instead of re-scanning the file systems.</p>
<ul>
<li></li>
</ul>
<p><strong>Expiry</strong>: By default, cache entries expire after <strong>15 minutes</strong>. This ensures that results remain fresh if the running system (<code>.</code>) is one of the comparison targets. Use <code>--cache-expires=EXPIRES_SECS</code> to override the default value (900s).</p>
<ul>
<li></li>
</ul>
<p><strong>Manual Control</strong>: You can override the expiry or disable the cache entirely using the <code>--cache-mode={auto,never,always}</code> and <code>--cache-expires=EXPIRES_SECS</code> options. These options are mutually exclusive.</p>
<h2 id="command-reference">Command Reference</h2>
<h3 id="the-snapm-command">The <code>snapm</code> Command</h3>
<p>The <code>snapm</code> command provides the CLI interface to the snapshot manager. It is able to create, delete, and display snapshots and snapshot sets and provides reports listing the snapshots, snapshot sets, and schedules available on the system. Each snapm command operates on a particular object type: a snapshot set, an individual snapshot, or a schedule.</p>
<pre data-lang="bash" style="background-color:#2b303b;color:#c0c5ce;" class="language-bash "><code class="language-bash" data-lang="bash"><span style="color:#bf616a;">snapm</span><span> snapset &lt;command&gt; &lt;options&gt; </span><span style="color:#65737e;"># snapset command
</span><span>
</span></code></pre>
<pre data-lang="bash" style="background-color:#2b303b;color:#c0c5ce;" class="language-bash "><code class="language-bash" data-lang="bash"><span style="color:#bf616a;">snapm</span><span> snapshot &lt;command&gt; &lt;options&gt; </span><span style="color:#65737e;"># snapshot command
</span><span>
</span></code></pre>
<h2 id="snapset-commands">Snapset Commands</h2>
<p>The <code>snapset</code> subcommand is used to create, delete, rename, activate, deactivate, list and display snapshot sets.</p>
<p>snapset create</p>
<p>Create a new snapshot set with the provided name and list of sources (mount point or block device paths):</p>
<pre data-lang="bash" style="background-color:#2b303b;color:#c0c5ce;" class="language-bash "><code class="language-bash" data-lang="bash"><span style="color:#bf616a;">snapm</span><span> snapset create </span><span style="color:#b48ead;">[</span><span>-b|--bootable</span><span style="color:#b48ead;">] [</span><span>-r|--revert</span><span style="color:#b48ead;">] [</span><span>--size-policy policy</span><span style="color:#b48ead;">] </span><span>&lt;name&gt; &lt;source&gt; </span><span style="color:#b48ead;">[</span><span>&lt;source&gt; ...</span><span style="color:#b48ead;">]
</span><span>
</span></code></pre>
<p>Per-source path size policies are specified by adding a ':' and the required policy to the corresponding mount point path, for example:</p>
<pre data-lang="bash" style="background-color:#2b303b;color:#c0c5ce;" class="language-bash "><code class="language-bash" data-lang="bash"><span style="color:#bf616a;">snapm</span><span> snapset create backup /:2G /var:1G /home
</span><span>
</span></code></pre>
<pre data-lang="bash" style="background-color:#2b303b;color:#c0c5ce;" class="language-bash "><code class="language-bash" data-lang="bash"><span style="color:#bf616a;">snapm</span><span> snapset create backup /:25%</span><span style="color:#bf616a;">FREE</span><span> /var:25%</span><span style="color:#bf616a;">FREE</span><span> /home
</span><span>
</span></code></pre>
<pre data-lang="bash" style="background-color:#2b303b;color:#c0c5ce;" class="language-bash "><code class="language-bash" data-lang="bash"><span style="color:#bf616a;">snapm</span><span> snapset create backup /:100%</span><span style="color:#bf616a;">USED</span><span> /var:100%</span><span style="color:#bf616a;">USED</span><span> /home
</span><span>
</span></code></pre>
<pre data-lang="bash" style="background-color:#2b303b;color:#c0c5ce;" class="language-bash "><code class="language-bash" data-lang="bash"><span style="color:#bf616a;">snapm</span><span> snapset create backup /:100%</span><span style="color:#bf616a;">SIZE</span><span> /var:100%</span><span style="color:#bf616a;">SIZE</span><span> /home
</span><span>
</span></code></pre>
<p>If no size policy is specified the default is <code>200%USED</code> for mounted file systems and 25%SIZE for unmounted block devices. To ensure a volume can be completely overwritten specify <code>100%SIZE</code>. This requires more storage capacity but avoids the possibility of the snapshot running out of space. A default size policy for all source paths that do not specify an explicit per-path policy can be set with the <code>--size-policy</code> argument:</p>
<pre data-lang="bash" style="background-color:#2b303b;color:#c0c5ce;" class="language-bash "><code class="language-bash" data-lang="bash"><span style="color:#bf616a;">snapm</span><span> snapset create backup</span><span style="color:#bf616a;"> --size-policy</span><span> 100%</span><span style="color:#bf616a;">SIZE</span><span> / /home /var
</span><span>
</span></code></pre>
<p>On success the <code>snapm snapset create</code> command displays the newly created snapshot set on stdout:</p>
<pre data-lang="bash" style="background-color:#2b303b;color:#c0c5ce;" class="language-bash "><code class="language-bash" data-lang="bash"><span style="color:#bf616a;">snapm</span><span> snapset create</span><span style="color:#bf616a;"> -br --size-policy</span><span> 100%</span><span style="color:#bf616a;">USED</span><span> backup / /home /var
</span><span style="color:#bf616a;">SnapsetName:</span><span> backup
</span><span style="color:#bf616a;">Sources:</span><span> /, /home, /var
</span><span style="color:#bf616a;">NrSnapshots:</span><span> 3
</span><span style="color:#bf616a;">Time:</span><span> 2024-12-05 19:10:44
</span><span style="color:#bf616a;">UUID:</span><span> d3f5e3cd-a383-5dba-b597-9134a2c426e9
</span><span style="color:#bf616a;">Status:</span><span> Active
</span><span style="color:#bf616a;">Autoactivate:</span><span> yes
</span><span style="color:#bf616a;">Bootable:</span><span> yes
</span><span style="color:#bf616a;">BootEntries:
</span><span> </span><span style="color:#bf616a;">SnapshotEntry:</span><span> f574a20
</span><span> </span><span style="color:#bf616a;">RevertEntry:</span><span> f428f9f
</span><span>
</span></code></pre>
<h4 id="autoindex-for-recurring-snapshot-sets">Autoindex for recurring snapshot sets</h4>
<p>The <code>--autoindex</code> argument allows creating a recurring snapshot set with a common basename and unique index (a non-negative integer). This can be used to take regular snapshots with a common name:</p>
<pre data-lang="bash" style="background-color:#2b303b;color:#c0c5ce;" class="language-bash "><code class="language-bash" data-lang="bash"><span style="color:#bf616a;">snapm</span><span> snapset create hourly</span><span style="color:#bf616a;"> --autoindex</span><span> /:25%</span><span style="color:#bf616a;">SIZE</span><span> /var:25%</span><span style="color:#bf616a;">SIZE
</span><span style="color:#bf616a;">SnapsetName:</span><span> hourly.3
</span><span style="color:#bf616a;">Sources:</span><span> /, /var
</span><span style="color:#bf616a;">NrSnapshots:</span><span> 2
</span><span style="color:#bf616a;">Time:</span><span> 2025-03-26 14:17:18
</span><span style="color:#bf616a;">UUID:</span><span> ae082452-7995-5316-ac65-388eadd9879c
</span><span style="color:#bf616a;">Status:</span><span> Active
</span><span style="color:#bf616a;">Autoactivate:</span><span> yes
</span><span style="color:#bf616a;">Bootable:</span><span> no
</span><span>
</span></code></pre>