Using Snapper snapshots in CentOS 7 for system backup and recovery

Using Snapper snapshots in CentOS 7 for system backup and recovery
Why use Snapper snapshot?

We can imagine the following scenarios:
1. Scenario 1: when the system goes down unexpectedly, Engineers cannot quickly locate the problem and the business is interrupted. The customer is very dissatisfied.
2. scenario 2: during the project meeting, whether or not to upgrade A software to the latest version will cause constant disputes between A and B. A believes that it cannot be easily upgraded to maintain compatibility with other software, B believes that the upgrade can fully utilize the latest features of the software package and enjoy the performance improvement of the new version.
3. scenario 3: The database suddenly fails to be accessed, resulting in service interruption. Engineers A and B are held accountable and cannot compete. A says that B has modified A certain configuration, B retorted that my configuration is correct and cannot be wrong.

However, Snapper can easily help you solve the above troubles:
1. Use Snapper to regularly back up the system. Unexpected system downtime can be quickly traced back to the previous normal state.
2. You can use Snapper to install/upgrade the software and take snapshots before and after the installation or upgrade. If the installation or upgrade fails, the system can be quickly restored to normal.
3. for deployment configuration of large software projects, Snapper can help to quickly locate which configuration files have been modified, help locate errors, and quickly cancel configuration file modifications.

"Thanks to Snapper, We can freely toss system configuration and install/update software, and recover from the old backup to a previous style," said Magazine, a Linux User and Developer, you don't have to worry about losing files. You just need to use snapshots to recover from bad points to better points.

Snapshot tool Snapper

A snapshot copies a volume at a certain point and provides a method to restore the file system to its previous state. Snapper is a command line tool used to create and maintain snapshots. It provides basic snapshot tools: Creating and deleting snapshots, comparing changes between snapshots, and canceling operations between snapshots.

Currently, Snapper can create snapshots for the following file system types:

• Btrfs
• Ext3, ext4, and xfs file systems created on thinly-provisioned LVM

Snapper is an open-source project based on GPLv2.0. Snapper is initiated and maintained by SUSE.
-Snapper official blog: http://snapper.io/
-Snapper Source Code released on github: https://github.com/openSUSE/snapper
-Snapper GUI (currently only btrfs, ext4, streamlined LVM are supported): https://github.com/ricardomv/snapper-gui
Snapper-gui is still in the development stage and has incomplete functions. For more information, see another blog post: Technology preview: Using Snapper GUI to manage system snapshots

SUSE snapshot solution:
-YaST/Zypper + Snapper + btrfs or thin-provisioning LVM
Provides YaST/Zypper interface operations and Snapper command lines;

CentOS snapshot solution:
-Snapper + btrfs or thin-provisioning LVM
The Snapper command line operation is provided. Users can experience how to use the open-source Snapper GUI as the upper-layer interface, but the functions are not complete.

Create a snapshot for the Btrfs file system to create a Btrfs Partition

First, we use the btrfs file system as an example to create a snapshot using Snapper;
To create a snapshot for a common btrfs file system, you must first create and mount the btrfs File System:

1. Create a btrfs File System

   # mkfs.btrfs /dev/sdb

2. Mount the btrfs File System

   # mount /dev/sdb /mnt

If you want to use snapshots to protect the root partition, You need to select btrfs as the root partition during installation, because the seven root partitions in CentOS are xfs file systems by default, therefore, during the installation process, select btrfs as the default file system for the root partition.

When a snapshot is created, both the snapshot and the original point to the same block in the file system. Therefore, snapshots do not occupy additional disk space at the beginning. However, if the data in the original file system is modified, the changed data block is copied and the old data block is retained as a snapshot. Therefore, snapshots occupy the same space as modified data. So over time, the space allocated to snapshots will continue to grow. Therefore, partitions that contain snapshots must be larger than normal partitions. The exact size of the space depends on the number of snapshots to be retained and the amount of data changes. Generally, two times the space used by the disk space should be considered.

1. Select "I will configure partitioning" and click "Done" to go to the next step:
   

2. Click "Click here to creat them automatically" to automatically add, or Click "+" to manually add:
   

3. Modify the file system type of the root partition to Btrfs:
   

4. After installation, the generated root partition file system is as follows:
   

Install snapper

Run the following command to install snapper:

# yum install snapper

Check whether the installation is successful.

# rpm -qa | grep snapper

Create a configuration file ###

Next, create a snapshot step by step. Snapper needs to create a configuration file for each volume. The configuration file defines the snapshot creation and maintenance rules, run the following command to create a configuration file btrfs_config for our root file system:

// snapper -c config_name create-config -f btrfs /mount-point# snapper -c btrfs_config create-config -f btrfs /

The created configuration file is generally copied from/etc/snapper/config-templates/default and generated in the/etc/snapper/configs/folder, we can see that the newly generated configuration file is as follows. Currently, the configuration file uses the default settings and does not modify its content for the moment:

# ls /etc/snapper/configs/btrfs_config

Snapshot creation type

Although there is no difference between different snapshots, they are divided into the following three categories based on different situations:
-Pre
The file system snapshot before modification. Each previous snapshot has a corresponding post snapshot.

• Post
  The modified File System Snapshot. Each post-Snapshot has a corresponding pre-snapshot.

• Single
  Independent snapshots. One of the purposes is to automatically create an hourly snapshot. This is the default type when a snapshot is created.

Create a pre or post Snapshot

You can create pre and post snapshots separately. For example, if you create a pre snapshot first,-p means that the snapshot number is printed at the same time:

# snapper -c btrfs_config create -t pre -p1# snapper -c btrfs_config listType   | # | Pre # | Date                            | User | Cleanup  | Description | Userdata-------+---+-------+---------------------------------+------+----------+-------------+---------single | 0 |       |                                 | root |          | current     |         pre    | 1 |       | Wed 08 Jun 2016 11:28:09 AM EDT | root |          |             | 

Then we may execute some system operations. For example, if we install a software package, the content of the root partition file system will change.

yum install net-tools

We can create a post snapshot:

# snapper -c btrfs_config create -t post --pre-num 1 -p2# snapper -c btrfs_config listType   | # | Pre # | Date                            | User | Cleanup  | Description | Userdata-------+---+-------+---------------------------------+------+----------+-------------+---------single | 0 |       |                                 | root |          | current     |         pre    | 1 |       | Wed 08 Jun 2016 11:28:09 AM EDT | root |          |             |         post   | 2 | 1     | Wed 08 Jun 2016 12:26:19 PM EDT | root |          |             |  

Snapshots numbered 1 and 2 form a snapshot pair, which records root partition changes before and after installing net-tools. Run the following command to view these changes:

# Snapper-c btrfs_config status 1 .. 2 + ..... /usr/bin/netstat + ..... /usr/lib/systemd/system/arp-ethers.service + ..... /usr/sbin/arp + ..... /usr/sbin/ether-wake + ..... /usr/sbin/ifconfig + ..... /usr/sbin/ipmaddr + ..... /usr/sbin/iptunnel + ..... /usr/sbin/mii-diag + ..... /usr/sbin/mii-tool + ..... /usr/sbin/nameif + ..... /usr/sbin/plipconfig + ..... /usr/sbin/route + ..... /usr/sbin/slattach + ..... /usr/share/doc/net-tools-2.0 + ..... /usr/share/doc/net-tools-2.0/COPYING (Omitted ...) + ..... /usr/share/man/pt/man8/route.8.gzc ..... /var/cache/yum/x86_64/7/timedhostsc ..... /var/lib/rpm/Basenamesc ..... /var/lib/rpm/Dirnames (Omitted ...) + ..... /var/lib/yum/yumdb/n/tests/var_infra + ..... /var/lib/yum/yumdb/n/examples/var_uuidc ..... /var/log/audit. logc ..... /var/log/cronc ..... /var/log/messagesc ..... /var/log/snapper. logc ..... /var/log/yum. log

"+" Indicates a new file, "-" indicates that the file is deleted, and "c" indicates that the file is modified, which is the same as the diff syntax.

Add description and user data for snapshots

Create a pre-type snapshot and print the snapshot number. The snapshot is marked as important and a description is added for it to facilitate future query:

# snapper create --type pre --print-number --description "Before install net-tools"--userdata "important=yes"

Create a post-type snapshot. The corresponding pre-Snapshot number is 1. the snapshot is marked as important and a description is added for it to facilitate future query:

# snapper create --type post --pre-number 1 --description "After install net-tools" --userdata "important=yes"

The preceding operations can also be combined into a command:

# snapper -c btrfs_config create --command "yum install net-tools"

View snapshots ###

Because the automatic snapshot function is enabled in the default configuration, the snapshot of the entire point is automatically recorded, that is, the timeline snapshot of the single type, we can see that Snapper automatically generates a snapshot named 3 (Note: if a snapshot is generated every hour, our system will be full of snapshots in a short time, it will crash due to insufficient storage space, so it is impossible to generate snapshots without limitation. This is the role of the snapshot clearing rules in the configuration file, only a limited number of snapshots of the current year, current month, and current day will be retained, which will be described in detail later. Here we will only preview them .)

# snapper -c btrfs_config listType   | #  | Pre # | Date                            | User | Cleanup  | Description | Userdata-------+----+-------+---------------------------------+------+----------+-------------+---------single | 0  |       |                                 | root |          | current     |         pre    | 1  |       | Wed 08 Jun 2016 01:15:16 PM EDT | root |          |             |         post   | 2  | 1     | Wed 08 Jun 2016 01:15:21 PM EDT | root |          |             |         single | 3  |       | Wed 08 Jun 2016 02:01:01 PM EDT | root | timeline | timeline    |         

Snapshot metadata

You can see from the snapshot list that each snapshot consists of the snapshot itself and some metadata. When creating a snapshot, you must specify the metadata. Modifying a snapshot means that only its metadata can be changed. The snapshot content cannot be changed. Each snapshot uses the following metadata:

Type: Snapshot Type. For more information, see snapshot Type, which cannot be changed; #: Unique ID of the snapshot, which cannot be changed; Pre #: ID of the corresponding previous snapshot, which is only applicable to post, cannot be changed; Date: snapshot creation timestamp User: Snapshot creation User Cleanup: cleaning Rule Description: Snapshot Description. Userdata: Extended description. You can use the comma-separated "Key = value" List format to specify the Custom Data "reason = testing, project = foo ", this field can also be used to mark a snapshot as important (important = yes) and list the users who created the snapshot (user = tux ).

View File changes

Displays a series of files changed in the specified snapshot. For example, run the following command to list the files/var/log/yum. the difference between the current version with the log label 0 and the file version in the snapshot with the log label 2. If the file name is not specified, the differences among all files are displayed:

# snapper -c btrfs_config diff 1..0 /var/log/yum.log--- /.snapshots/1/snapshot/var/log/yum.log  2016-06-08 13:01:51.977879395 -0400+++ /var/log/yum.log    2016-06-08 13:47:50.520081926 -0400@@ -3,3 +3,12 @@ Jun 08 08:15:18 Installed: snapper-libs-0.1.7-10.el7.x86_64 Jun 08 08:15:18 Installed: boost-serialization-1.53.0-25.el7.x86_64 Jun 08 08:15:19 Installed: snapper-0.1.7-10.el7.x86_64+Jun 08 13:15:21 Installed: net-tools-2.0-0.17.20131004git.el7.x86_64+Jun 08 13:47:47 Updated: 7:device-mapper-1.02.107-5.el7_2.2.x86_64+Jun 08 13:47:47 Updated: 7:device-mapper-libs-1.02.107-5.el7_2.2.x86_64+Jun 08 13:47:47 Installed: 7:device-mapper-event-libs-1.02.107-5.el7_2.2.x86_64+Jun 08 13:47:48 Installed: 7:device-mapper-event-1.02.107-5.el7_2.2.x86_64+Jun 08 13:47:48 Installed: 7:lvm2-libs-2.02.130-5.el7_2.2.x86_64+Jun 08 13:47:48 Installed: libaio-0.3.109-13.el7.x86_64+Jun 08 13:47:48 Installed: device-mapper-persistent-data-0.5.5-1.el7.x86_64+Jun 08 13:47:50 Installed: 7:lvm2-2.02.130-5.el7_2.2.x86_64

If a new file is added, only:

# snapper -c btrfs_config diff 1..0 /usr/bin/netstatBinary files /.snapshots/1/snapshot/usr/bin/netstat and /usr/bin/netstat differ

Run the following command to list the differences between the file versions of the/var/log/yum. log file in the snapshots marked as 1 and 2:

# Snapper-c btrfs_config diff 1 .. 2/var/log/yum. log (Omitted ...)

The preceding command shows that the Snapper snapshot is stored in the. snapshots hidden folder in the root directory of the current sub-volume. For example, if the current sub-volume is/, it is/. snapshots. If it is/mnt/vol1, It is/mnt/vol1/. snapshots. Snapshots are always stored in the partition or sub-volume of the created snapshot. Snapshots cannot be stored in other partitions or sub-volumes.

Restore Files

To restore one or more files, run

# snapper -c CONFIG -v undochange  SNAPSHOT_ID..0 FILENAME1 FILENAME2

If no file name is specified, all changed files will be restored. You can use the following command to restore the system to snapshot 1:

# snapper -c btrfs_config undochange 1..2

Delete a snapshot

You can run the following command to delete a snapshot:

# snapper -c btrfs_config delete 1 2# snapper -c btrfs_config listType   | # | Pre # | Date | User | Cleanup | Description | Userdata-------+---+-------+------+------+---------+-------------+---------single | 0 |       |      | root |         | current     |  

Tip: more disk space is occupied by the old snapshot !!!
If you want to delete a snapshot to release space on the hard disk, you must first Delete the old snapshot. The longer the snapshot is generated, the more space it occupies. You can use the configuration file to automatically delete snapshots. For more information, see clear algorithms.

Create a snapshot on a streamlined LVM volume

In addition to generating snapshots on the Btrfs file system, the snapshot program also supports generating snapshots on thin LVM volumes in XFS, Ext4, or Ext3 format (snapshots cannot be generated on conventional LVM volumes.

Create a streamlined LVM

Take/dev/sdb and/dev/sdc on the system as examples. First, create the partition/dev/sdb1 and/dev/sdc1 respectively:

# fdisk /dev/sdb Welcome to fdisk (util-linux 2.23.2).Changes will remain in memory only, until you decide to write them.Be careful before using the write command.Device does not contain a recognized partition tableBuilding a new DOS disklabel with disk identifier 0x962bc2ec.Command (m for help): nPartition type:   p   primary (0 primary, 0 extended, 4 free)   e   extendedSelect (default p): Using default response pPartition number (1-4, default 1): First sector (2048-10485759, default 2048): Using default value 2048Last sector, +sectors or +size{K,M,G} (2048-10485759, default 10485759): Using default value 10485759Partition 1 of type Linux and of size 5 GiB is setCommand (m for help): wThe partition table has been altered!Calling ioctl() to re-read partition table.Syncing disks.

View the created partitions as follows:

# lsblkNAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTfd0      2:0    1    4K  0 disk sda      8:0    0   30G  0 disk +-sda1   8:1    0  500M  0 part /boot+-sda2   8:2    0    2G  0 part [SWAP]+-sda3   8:3    0 27.5G  0 part /homesdb      8:16   0    5G  0 disk +-sdb1   8:17   0    5G  0 part sdc      8:32   0    5G  0 disk +-sdc1   8:33   0    5G  0 part sr0     11:0    1 1024M  0 rom  

Create PV:

# pvcreate /dev/sdb1  Physical volume "/dev/sdb1" successfully created# pvcreate /dev/sdc1  Physical volume "/dev/sdc1" successfully created

Create VG:

# vgcreate vg_thin /dev/sdb1 /dev/sdc1   Volume group "vg_thin" successfully created

Create a streamlined pool:

# lvcreate -L 5G --thinpool thin_pool vg_thin  Logical volume "thin_pool" created.

Check the streamlined LVM. We can see that the Allocated pool data is 0, indicating that thin_pool has not actually occupied disk space:

# lvdisplay /dev/vg_thin/thin_pool   --- Logical volume ---  LV Name                thin_pool  VG Name                vg_thin  LV UUID                3811nd-ltYk-XWqO-mxog-Gq82-38do-BywBfY  LV Write Access        read/write  LV Creation host, time localhost.localdomain, 2016-06-08 14:05:58 -0400  LV Pool metadata       thin_pool_tmeta  LV Pool data           thin_pool_tdata  LV Status              available  # open                 0  LV Size                5.00 GiB  Allocated pool data    0.00%  Allocated metadata     0.68%  Current LE             1280  Segments               1  Allocation             inherit  Read ahead sectors     auto  - currently set to     8192  Block device           253:2

Create a thin volume thin_vol1, thin_vol2, and thin_vol3. Ignore the warning. You can see that the size of the three 2G thin volumes is greater than the size of the 5G thin pool thin_pool, But the creation is still successful, for more information about how to allocate excess traffic, see Thin provisioning.

# lvcreate -V 2G --thin -n thin_vol1 vg_thin/thin_pool  Logical volume "thin_vol1" created.# lvcreate -V 2G --thin -n thin_vol2 vg_thin/thin_pool  Logical volume "thin_vol2" created.# lvcreate -V 2G --thin -n thin_vol3 vg_thin/thin_pool6 GiB)!  For thin pool auto extension activation/thin_pool_autoextend_threshold should be below 100.  Logical volume "thin_vol3" created.

Create a file system:

# mkfs.ext4 /dev/vg_thin/thin_vol1

Mount a file system:

# mkdir /mnt/vol1# mount /dev/vg_thin/thin_vol1 /mnt/vol1

Create a snapshot configuration file

To use the snapshot program on a streamlined LVM volume, you must first create a snapshot configuration file for it. On LVM, use-fstype = lvm (filesystem) to specify the file system. The valid values of the file system are ext3, etx4, and xfs. As follows:

# snapper -c lvm_config create-config -f "lvm(ext4)" /mnt/vol1/# ls /etc/snapper/configs/btrfs_config  lvm_config  # snapper -c lvm_config listType   | # | Pre # | Date | User | Cleanup | Description | Userdata-------+---+-------+------+------+---------+-------------+---------single | 0 |       |      | root |         | current     |  

Create a set of pre/post snapshot Pairs

# snapper -c lvm_config create --command "echo Hello > /mnt/vol1/hello_file"# snapper -c lvm_config listType   | # | Pre # | Date                            | User | Cleanup | Description | Userdata-------+---+-------+---------------------------------+------+---------+-------------+---------single | 0 |       |                                 | root |         | current     |         pre    | 1 |       | Wed 08 Jun 2016 02:41:07 PM EDT | root |         |             |         post   | 2 | 1     | Wed 08 Jun 2016 02:41:07 PM EDT | root |         |             |   

View changes between snapshot 1 and snapshot 2

# snapper -c lvm_config diff 1..2--- /mnt/vol1/.snapshots/1/snapshot/hello_file  1969-12-31 19:00:00.000000000 -0500+++ /mnt/vol1/.snapshots/2/snapshot/hello_file  2016-06-08 14:41:07.860147086 -0400@@ -0,0 +1 @@+Hello

Use snapshots as normal users

By default, the snapshot program can only be used by the root user. However, under certain circumstances, some groups or users also need to create snapshots or restore them to the snapshots to cancel the changes:

Set values for ALLOW_USERS and (or) ALLOW_GROUPS to grant permissions to users and (or) groups respectively. Multiple entries must be separated by spaces. For example, to grant permissions to users thin_user and thin_group, run:

# snapper -c web_data set-config "ALLOW_USERS=thin_user" "ALLOW_GROUPS=thin_group"

You can also directly modify the configuration file. In this case, the specified user and (or) group can be configured using the specified snapshot program. You can use the list command to test it. For example:

# thin_user:~ > snapper -c lvm_config list

The following describes some advanced configurations:

Custom settings

All of the preceding settings use the default settings/etc/Snapper/config-templates/default provided by snapper to create a configuration file. This default configuration file is suitable for most scenarios after many considerations. You can also customize how to create automatic snapshots and how to retain snapshots as needed.

Each configuration contains a series of options that can be modified through the command line:

# snapper -c btrfs_config set-config "TIMELINE_CREATE=yes"

• FSTYPE
  Partition file system types: btrfs, lvm (ext3), lvm (ext4), and lvm (xfs). The snapshot type cannot be changed.

• SUBVOLUME
  The Installation Point of the snapshot generated by the partition or sub-volume. It cannot be changed.

• BACKGROUND_COMPARISON
  Determine whether to compare snapshots before and after they are created in the background. The default value is "yes ".

Disable/enable timeline snapshots

By default, timeline snapshots are enabled. You can directly change TIMELINE_CREATE in the configuration file to yes/no, or start or stop a snapshot by running the following command:
-Enable

    # snapper -c btrfs_config set-config "TIMELINE_CREATE=yes"

• Disable

  # snapper -c btrfs_config set-config "TIMELINE_CREATE=no"

Control snapshot archiving interval (Clearing Rules)

Snapshots occupy disk space. To prevent system interruption due to insufficient disk space, the old snapshots are automatically deleted:

Cleaning Algorithm

Snapper provides three algorithms for clearing old snapshots. These algorithms are executed as daily scheduled jobs. You can define the number of different types of snapshots to be retained in the Snapper Configuration:

• Number
  When a snapshot count is reached, the old snapshot is deleted.

• Timeline
  Old snapshots that have exceeded a certain period of time are deleted, but a certain amount of snapshots are retained per hour, day, month, and year.

• Empty-pre-post
  Before and after the snapshot is deleted.

Snapper uses the following configuration options to control snapshot cleanup rules:

• TIMELINE_CLEANUP
  Determines whether to automatically delete the old snapshot when the number of snapshots exceeds the value specified by the TIMELINE_LIMIT _ * option and the snapshot exceeds the value specified in TIMELINE_MIN_AGE. Valid values: yes and no. The default value is yes ".

• TIMELINE_CREATE
  If yes, a snapshot is created every hour. This is currently the only way to automatically create snapshots. Therefore, we strongly recommend that you set it to yes. Valid values: yes and no. The default value is yes ".

• TIMELINE_MIN_AGE
  Defines the minimum time limit (in seconds) That snapshots must be retained before they are automatically deleted ).
  The default value is 1800 ".

• TIMELINE_LIMIT_DAILY, TIMELINE_LIMIT_HOURLY, TIMELINE_LIMIT_MONTHLY, TIMELINE_LIMIT_YEARLY
  The number of snapshots retained by hour, day, month, or year. The default value of each item is "10 ".

  TIMELINE_CLEANUP = "yes"
  TIMELINE_CREATE = "yes"
  TIMELINE_LIMIT_DAILY = "10"
  TIMELINE_LIMIT_HOURLY = "10"
  TIMELINE_LIMIT_MONTHLY = "10"
  TIMELINE_LIMIT_YEARLY = "10"
  TIMELINE_MIN_AGE = "1800"

Hourly: 10 snapshots created recently.
Daily: retain the first snapshot created every day in the last ten days.
Monthly: retain the first snapshot created on the last day of each month in the last ten months.
Annual: retain the first snapshot created on the last day of each year in the last ten years.

In this example, you can generate snapshots that will be automatically cleaned up on an hourly basis. TIMELINE_MIN_AGE and TIMELINE_LIMIT _ * are always evaluated at the same time. In this example, the minimum retention period before the snapshot is deleted is set to 30 minutes (1800 seconds ). Because we create a snapshot every hour, we make sure that only the latest snapshot is retained. If TIMELINE_LIMIT_DAILY is set to a non-zero value, the first snapshot of the day will be retained.

• NUMBER_CLEANUP
  Determines whether to automatically delete the old snapshot when the total number of snapshots exceeds the value specified in NUMBER_LIMIT and the number of snapshots exceeds the value specified in NUMBER_MIN_AGE. Valid values: yes and no. The default value is yes ".

• NUMBER_LIMIT
  When NUMBER_CLEANUP is set to yes, define the number of installation and management snapshot pairs that are not marked as important. The latest snapshots are retained. The default value is "50 ".

• NUMBER_LIMIT_IMPORTANT
  When NUMBER_CLEANUP is set to yes, define the snapshot logarithm marked as important. The latest snapshots are retained. The default value is 10 ".

• NUMBER_MIN_AGE
  Defines the minimum retention period (in seconds) of a snapshot before it is automatically deleted ). The default value is "1800", that is, 30 minutes.

Note: Restrictions and time limits
NUMBER_LIMIT, NUMBER_LIMIT_IMPORTANT, and NUMBER_MIN_AGE are always evaluated. Snapshots are deleted only when all the conditions are met. If you want to retain a certain number of snapshots without considering the time limit, you can set NUMBER_MIN_AGE to 0. In addition, if you do not want to retain a snapshot after it exceeds a certain time limit, you can set NUMBER_LIMIT and NUMBER_LIMIT_IMPORTANT to 0.

Processing of null snapshots

EMPTY_PRE_POST_CLEANUP
If yes, the system will delete the same snapshot pair before and after the snapshot. The default value is "yes ".

EMPTY_PRE_POST_MIN_AGE
Defines the minimum retention time (in seconds) that must be retained before and after automatic deletion of the same snapshot ). The default value is 1800 ".

Manage existing configurations

Snapper has multiple sub-commands for managing existing configurations. You can list, display, or delete or modify these configurations:

List configurations

Run the following command to display all existing configurations:

# snapper list-configsConfig       | Subvolume-------------+----------btrfs_config | /        lvm_config   | /mnt/vol1

View configurations

Use the snapper-c CONFIG get-config sub-command to display the specified configuration. CONFIG should be replaced with a configuration name displayed after the snapper list-configs command is executed. For more information about configuration options, see configuration data.

Delete Configuration

Run the following command to delete the Configuration. CONFIG should be replaced with a configuration name displayed after the snapper list-configs command is executed:

# snapper -c CONFIG delete-config

Modify configurations

Use the following command to modify the options in the specified configuration. CONFIG should be replaced with a configuration name displayed after the snapper list-configs command is executed. For the possible values of OPTION and VALUE, see configuration data:

# snapper -c CONFIG set-config OPTION=VALUE

Data Consistency

There is no mechanism to ensure data consistency when creating snapshots. If a file (such as a database) is written while a snapshot is created, the file is damaged or the write is incomplete. Restoring such files may cause problems. In addition, some system files (such as/etc/mtab) cannot be recovered. Therefore, we strongly recommend that you always carefully check the list of changed files and their differences. Only the files that are actually included in the operations you want to restore are restored.

Modify snapshot metadata

You can use the snapshot program to modify instructions, clear algorithms, and user data of snapshots. Other metadata cannot be changed.

Use snapper list to view all snapshots and their IDs

# snapper -c btrfs_config list 

Modify the metadata of the 10th snapshots configured in btrfs_cconfig and set the cleanup algorithm to timeline:

# snapper -c btrfs_config modify --cleanup-algorithm "timeline" 10

Modify the metadata of the 12th snapshots configured in btrfs_cconfig, set a new description, and cancel setting the cleanup algorithm:

# snapper --config btrfs_config modify --description "daily backup" -cleanup-algorithm "timeline" 120

Set filter rules

Some files are mainly used to save system information, such as/etc/mtab. These files do not want to be affected by snapshot operations. Snapper allows/etc/snapper/filters /*. txt specifies the filter item and ignores the changes to the specified file or folder in the snapshot operation.
For example, in our btrfs, we do not want snapshot tracking/var,/tmp, and so on. We can add them to filters, in this way, you will not be able to see the/var and/tmp snapshot tracking in the snapshots created later.