System backup and recovery using snapper snapshots in CentOS 7

Why use snapper snapshots?

We can imagine the following scenarios:
1. Scenario One: The system has an unexpected outage, the engineer can not quickly locate the problem, the business was interrupted, the customer is very dissatisfied.
2. Scenario two: At the project meeting, on whether to upgrade a software to the latest version, A and B are constantly arguing, a that in order to maintain compatibility with other software can not easily upgrade, B think the upgrade can take full advantage of the latest features of the package and enjoy the new version of the performance of the upgrade
3. Scenario three: The server suddenly inaccessible, resulting in business interruption, engineers A and b because of accountability, a said B modified a configuration caused, B retort that my configuration is correct, can not be wrong.

But snapper can easily help you solve the above problems:
1. Use Snapper to do a regular system backup, the system has an unexpected outage can quickly back to the previous normal state.
2. You can use Snapper to install/upgrade the software, take a snapshot before and after the installation/upgrade, if the installation/upgrade fails, you can quickly restore the system to a normal state
3. Deployment configuration for large software projects, snapper can help quickly locate which configuration files have been changed, help locate errors, and quickly undo configuration file modifications.

About Snapper,linux User & Developer magazine said: "Thanks to snapper, we can recklessly toss the system configuration and install/update software, from the old backup to revert to the past style, You don't have to worry about losing files anymore, you just need to take a snapshot to recover from the bad point to the better.

Snapshot tool Snapper

Snapshots are copies of a volume at a point, providing a way to restore the file system to its previous state. Snapper is a command-line tool for creating and maintaining snapshots, providing basic snapshot tools: creating, deleting snapshots, comparing changes between snapshots, and undoing actions between snapshots.

Currently snapper can create snapshots for the following file system types:

• Btrfs
• Ext3, EXT4, XFS file systems created on top of thinly-provisioned LVM

Snapper is an open source project that is based on the GPLv2.0 release. Snapper is initiated and maintained by SuSE.
-Snapper Official Blog for: http://snapper.io/
-Snapper Source published in Github:https://github.com/opensuse/snapper
-Snapper GUI (currently supports btrfs, EXT4, thin LVM only): Https://github.com/ricardomv/snapper-gui
Snapper-gui is still in the development stage, the function is not perfect, the introduction please refer to another blog: Technology Preview: Manage system snapshots with Snapper GUI

The SuSE snapshot scenario is:
-Yast/zypper + Snapper + btrfs or thin-provisioning LVM
By providing Yast/zypper interface operation and snapper command line;

The CentOS snapshot scenario is:
-Snapper + btrfs or thin-provisioning LVM
With snapper command-line operation, users can experience how to use the open source Snapper GUI as the upper interface, but the functionality is not yet complete.

Create a Btrfs partition for a Btrfs file system snapshot creation

First, we take the Btrfs file system as an example to create a snapshot using Snapper;
If you want to create a snapshot for a normal Btrfs file system, you need to create and mount the Btrfs file system first:

1. Create a Btrfs file system

   # mkfs.btrfs /dev/sdb

2. Mount Btrfs File System

   # mount /dev/sdb /mnt

If you want to take advantage of the snapshot to protect the root partition, you need to select Btrfs as the root partition at installation, because the CentOS 7 root partition is the Xfs file system by default, so choose Btrfs as the root partition default file system during the installation process.

When you create a snapshot, both the snapshot and the original point point to the same block in the file system. As a result, snapshots do not occupy additional disk space at first. However, if you modify the data in the original file system, the changed data blocks are copied, and the old chunks are retained as snapshots. Therefore, the snapshot will occupy the same space as the modified data. So over time, the space allocated to the snapshot is growing. Therefore, the partition that contains the snapshot needs to be larger than the regular partition. The exact size of the space depends primarily on the number of snapshots to keep and the amount of data changes. In general, you should consider using two times the amount of space you normally use for disk space.

1. Select "I'll Configure Partitioning" and click "Done" to proceed to the next step:
   

2. Click ' Click here to creat them automatically ' to add it automatically, or click ' + ' to add it manually:
   

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

4. To complete the above, the root partition file system generated after installation is as follows:
   

Installing snapper

Execute the following command to install Snapper:

# yum install snapper

Check after installation is complete to ensure successful installation

# rpm -qa | grep snapper

Create configuration File # # #

The next step is to create a snapshot, snapper need to create a profile for each volume, the configuration file defines the snapshot creation and maintenance rules, and executes the following command to create a configuration file named 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 profile created is typically copied from/etc/snapper/config-templates/default and generated under the/etc/snapper/configs/folder, and we can see the newly generated configuration file as follows, The current configuration file takes the default setting and does not modify its contents:

# ls /etc/snapper/configs/btrfs_config

To create a snapshot snapshot type

Although there are no differences between the different snapshots themselves, they are divided into the following three categories based on the different scenarios in which they are generated:
-Pre
The file system snapshot before the modification. Each of the previous snapshots has a corresponding post snapshot.

• Post
  The modified file system snapshot. Each post-snapshot has a corresponding pre-snapshot.

• Single
  A separate snapshot. One purpose is to automatically create hourly snapshots. This is the default type when the snapshot is created.

Create a pre or post snapshot

You can create a pre and post snapshot separately, for example, if we create a pre snapshot, the meaning of-p is to print out the snapshot number while creating the snapshot:

# 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 |          |             

After that we may perform some system operations, such as we have installed a package, the root partition file system content will have some changes

yum install net-tools

We can create a post snapshot at:

# 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 make up a snapshot pair that records the changes in the root partition before and after the installation of net-tools, viewing these changes with the following command:

  # 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 (slightly ...) + ...../usr/share/man/pt/man8/route.8.gzc ...../var/cache/yum/x86_64/7/timedhostsc .../var/lib/rpm/basenamesc ..../var/lib/rpm/dirnames (A little ...) + ...../var/lib/yum/yumdb/n/6a2a1ded37167c106d2be6dbec20003079f37cf6-net-tools-2.0-0.17.20131004git.el7-x86_64/ var_infra+ .../var/lib/yum/yumdb/n/ 6A2A1DED37167C106D2BE6DBEC20003079F37CF6-NET-TOOLS-2.0-0.17.20131004GIT.EL7-X86_64/VAR_UUIDC .../var/log/ AUDIT/AUDIT.LOGC ..../var/log/cronc .../var/log/messagesc ....../var/log/snapper.logc ...../var/log/yum.log 

The "+" sign represents the new file, "-" represents the delete file, "C" represents the modified file, same as the diff syntax.

Add a description and user data to a snapshot

Create a snapshot of the pre type and print the snapshot number, which is marked as important and adds a description to facilitate later querying:

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

Create a snapshot of the post type with the corresponding pre snapshot number 1, which is marked as important, and a description is added to facilitate later querying:

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

The above actions can also be combined into one command:

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

View Snapshot # # #

Because of the default configuration, the automatic snapshot feature is started, the snapshot of the hour is automatically recorded, or the timeline snapshot of type single, we can see that the snapper automatically generates a snapshot labeled 3 (Note: If a snapshot is generated every hour, it won't be long before our system is fully occupied by the snapshot. , it will crash because of insufficient storage space, so it is impossible to generate a snapshot indefinitely, this is the role of snapshot cleanup rules in the configuration file, only a limited number of the current year, the month, the day snapshot, will be explained in detail, here only to do a preview. ）

# 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 meta data

As you can see from the snapshot list above, each snapshot is made up of the snapshot itself and some meta data. When you create a snapshot, you specify metadata. Modifying a snapshot means that only its metadata can be changed, and the snapshot content cannot be changed. The metadata used for each snapshot is as follows:

Type：          快照类型，有关详细信息请参见快照类型，不能更改；#：             快照的唯一编号，不能更改；Pre #：         指定相应前快照的编号，仅适用于post，不能更改；Date：          创建快照的时间戳User：          创建快照的用户Cleanup：       清理规则Description：   快照的说明。Userdata：      扩展的说明。可使用逗号分隔的“键=值”列表格式指定自定义数据“reason=testing, project=foo”，此字段也可用于将快照标记为重要 (important=yes) 以及列出创建快照的用户 (user=tux)。

Viewing changes to a file

Displays a series of files that have changed in the specified snapshot, for example, by running the following command to list the differences in the file version of the current version of the file/var/log/yum.log with the label 2 in the 0, and if you do not specify a file name, the difference is displayed for all files:

# 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:15:18 Instal led:snapper-libs-0.1.7-10.el7.x86_64 June 08:15:18 installed:boost-serialization-1.53.0-25.el7.x86_64 June 08 08:15:19 Installed:snapper-0.1.7-10.el7.x86_64+jun 13:15:21 installed:net-tools-2.0-0.17.20131004git.el7.x86_64 +jun 13:47:47 Updated:7:device-mapper-1.02.107-5.el7_2.2.x86_64+jun 13:47:47 updated:7: Device-mapper-libs-1.02.107-5.el7_2.2.x86_64+jun 13:47:47 installed:7:device-mapper-event-libs-1.02.107-5.el7_ 2.2.x86_64+jun 13:47:48 Installed:7:device-mapper-event-1.02.107-5.el7_2.2.x86_64+jun 13:47:48 installed:7: Lvm2-libs-2.02.130-5.el7_2.2.x86_64+jun 13:47:48 Installed:libaio-0.3.109-13.el7.x86_64+jun 13:47:48 Installed : Device-mapper-persistent-data-0.5.5-1.el7.x86_64+jun 13:47:50 installed:7:lvm2-2.02.130-5.el7_2.2.x86_64 

If this is a new file, it will only be displayed:

# 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 in file versions of file/var/log/yum.log in the snapshot labeled 1 and 2:

# snapper -c btrfs_config diff 1..2 /var/log/yum.log(略...)

As you can see from the above command, the Snapper snapshot is stored in the. Snapshots hidden folder in the root directory of the current sub-volume. For example the current sub-volume is/, then is/.snapshots, if it is/mnt/vol1, that is/mnt/vol1/.snapshots. The snapshot is always stored in the same partition or sub-volume where the snapshot was created, and the snapshot cannot be stored to another partition or sub-volume.

Recover files

To recover one or more files, run

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

If you do not specify a file name, all the changed files will be restored, and you can undo the above operation with the following command to restore the system state to Snapshot 1:

# snapper -c btrfs_config undochange 1..2

Deleting a snapshot

You can delete a snapshot by using the following command:

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

Hint: The old snapshot occupies more disk space!!!
If you want to delete a snapshot to free up space on your hard disk, be sure to delete the old snapshot first. The longer the snapshot is generated, the greater the space it occupies. The snapshot is automatically deleted from the configuration file settings. For more information, see Cleanup algorithm.

To create a snapshot on a thin LVM volume

In addition to generating snapshots on a Btrfs file system, the snapshot program supports snapshot generation on thin LVM volumes in XFS, EXT4, or EXT3 formats that do not support snapshot generation on regular LVM volumes.

Create Thin LVM

Taking the/dev/sdb and/DEV/SDC of the system as an example, we first create the partition/DEV/SDB1,/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

To create a thin pool:

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

Viewing thin LVM, you can see that allocated pool data is 0, indicating that Thin_pool has not actually consumed 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, thin_vol3, ignore the warning, you can see three 2G of thin volume add already more than 5G thin pool thin_pool size, but the creation is still successful, as to why can be over-allocated, Refer to the automatic thin provisioning (Thin provisioning) Introduction

# 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.

To create a file system:

# mkfs.ext4 /dev/vg_thin/thin_vol1

Mount File System:

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

To create a snapshot configuration file

To use the snapshot program on a thin LVM volume, first create a snapshot profile for it. Use –FSTYPE=LVM (filesystem) to specify the file system on the LVM. Valid values for the file system are ext3, etx4, or 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     |  

Creates 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 snapshots 1 and 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

Using snapshots as a normal user

By default, the snapshot program can only be used by the root user. However, in certain situations, some groups or users also need to create snapshots or undo changes by reverting to a snapshot:

Set values for Allow_users and/or allow_groups to grant permissions to users and/or groups, respectively. Multiple entries need to be separated by spaces. For example, to grant permissions to users Thin_user and Thin_group, you can run:

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

You can also modify the configuration file implementation directly, at which point the specified user and/or group can use the specified snapshot program configuration. You can use the List command to test it, for example:

# thin_user:~ > snapper -c lvm_config list

The basic operation of the explanation to this end, the following is a few advanced configuration:

Custom settings

We are all using the Snapper default settings/etc/snapper/config-templates/default Create a configuration file, which is considered in many ways and is suitable for most use cases. Users can also customize how to create automatic snapshots and how to keep them, depending on their needs.

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

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

• Fstype
  The file system type of the partition: Btrfs, LVM (ext3), LVM (EXT4), LVM (XFS), the snapshot type cannot be changed.

• Subvolume
  A partition or a sub-volume generates a snapshot of the installation point. cannot be changed.

• Background_comparison
  Define whether you want to compare them in the background after the snapshot is created. The default value is "Yes".

disabling/enabling Timeline snapshots

The timeline snapshot is enabled by default, and you can directly modify the timeline_create in the configuration file to yes/no, or you can start and stop with 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 archive interval (cleanup rule)

The snapshot consumes disk space. To prevent the system from running out of disk space, the old snapshot is automatically deleted:

Cleanup algorithm

Snapper provides three algorithms for cleaning up old snapshots. These algorithms are executed on a daily scheduled basis. You can define the number of different types of snapshots to keep in the Snapper configuration:

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

• Timeline
  Old snapshots that exceed a certain time limit are deleted, but a certain amount of hourly, daily, monthly, and yearly snapshots are retained.

• Empty-pre-post
  The no-difference pre-and post-snapshot pairs are removed.

Snapper controls the cleanup rules for snapshots by using the following configuration options:

• Timeline_cleanup
  Defines whether the old snapshot is automatically deleted when the number of snapshots exceeds the value specified by the timeline_limit_* option and the snapshot exceeds the time limit specified in Timeline_min_age. Valid values: Yes, no, the default value is "Yes".

• Timeline_create
  If set to Yes, a snapshot is created every hour. This is the only way to automatically create a snapshot at the moment, so it is strongly recommended that you set it to Yes. Valid values: Yes, no, the default value is "Yes".

• Timeline_min_age
  Defines the minimum time (in seconds) that a snapshot must be retained before it is automatically deleted.
  The default value is "1800".

• Timeline_limit_daily, Timeline_limit_hourly, timeline_limit_monthly, timeline_limit_yearly
  Number of snapshots reserved by hour, day, month, year. The default value for 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: The 10 most recently created snapshots.
Daily: Retains the first snapshot created daily within the last 10 days.
Monthly: Retains the first snapshot that was created on the last day of the month in the past 10 months.
Yearly: Retains the first snapshot created on the last day of each year in the last 10 years.

This sample configuration enables snapshots that are automatically cleaned up by hour generation. Timeline_min_age and timeline_limit_* are always evaluated at the same time. In this example, the minimum retention period before snapshot deletion is set to 30 minutes (1800 seconds). Because we create snapshots every hour, we ensure that only the most recent snapshots are kept. If Timeline_limit_daily is set to a value other than 0, the first snapshot of the day is also preserved.

• Number_cleanup
  Defines whether the old snapshot is automatically deleted when the total number of snapshots exceeds the value specified in Number_limit, and the snapshot exceeds the time limit specified in Number_min_age. Valid values: Yes, no, the default value is "Yes".

• Number_limit
  When Number_cleanup is set to Yes, you define the number of installation snapshot pairs and management snapshot pairs that you want to keep that are not marked as important. The snapshots that are kept are the latest ones. The default value is "50".

• Number_limit_important
  When Number_cleanup is set to Yes, the log of the snapshot that is to be retained is defined as important. The snapshots that are kept are the latest ones. The default value is "10".

• Number_min_age
  Defines the minimum time (in seconds) that a snapshot must be retained before it is automatically deleted. The default value is "1800", which is 30 minutes.

Note: Limitations and time limits
Number_limit, Number_limit_important and Number_min_age will always be evaluated. The snapshot is deleted only if all conditions are met at the same time. If you want to always keep a certain number of snapshots regardless of the time limit, you can set Number_min_age to 0. Also, if the snapshot does not want to be retained after a certain time limit, you can set Number_limit and number_limit_important to 0.

Processing of empty snapshots

Empty_pre_post_cleanup
If set to Yes, the system deletes the same snapshot pair before and after the snapshot. The default value is "Yes".

Empty_pre_post_min_age
Defines the minimum time (in seconds) that a snapshot of the same before and after snapshot must be retained before it is automatically deleted. The default value is "1800".

Managing Existing Configurations

Snapper has multiple subcommands that can be used to manage existing configurations. You can list, display, or delete and modify these configurations:

List configurations

Use the following command to display all existing configurations:

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

View Configuration

The specified configuration can be displayed using the Snapper-c CONFIG get-config subcommand. Config should be replaced with a configuration name that is displayed after the Snapper list-configs command is executed. See Configuration data For more information about configuration options.

Delete Configuration

Use the following command to delete a configuration. Config should be replaced with a configuration name that is displayed after the Snapper list-configs command is executed:

# snapper -c CONFIG delete-config

Modify Configuration

Use the following command to modify the options in the specified configuration. Config should be replaced with a configuration name that is displayed after the Snapper list-configs command is executed. The possible values for OPTION and value are described in configuration data:

# snapper -c CONFIG set-config OPTION=VALUE

About data consistency

There is no mechanism to ensure data consistency when creating snapshots. If you write a file (such as a database) at the same time as the snapshot is created, the file is corrupted or the write is incomplete. Restoring such files can cause problems. Also, some system files, such as/etc/mtab, can never be recovered. so = = strongly recommend = = You should always carefully review the list of changed files and their differences. Restore only the files that you want to restore that really contain.

modifying snapshot metadata

Users can use the snapshot program to modify the description, cleanup algorithm, and user data for the snapshot, and other metadata cannot be changed.

Use Snapper list to view all snapshots and their numbers

Modify the metadata for the 10th snapshot of the Btrfs_cconfig configuration and set the cleanup algorithm to timeline:

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

Modify the metadata for the 12th snapshot named Btrfs_cconfig configuration, set a new description, and de-set the cleanup algorithm:

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

Set filter Rules

Some files are primarily used to hold system information, such as/etc/mtab, which do not want to be affected by snapshot operations, Snapper allows the filtering of items to be specified through/etc/snapper/filters/*.txt, and ignores changes to the specified file or folder in the snapshot operation.
For example, in our btrfs we do not want snapshot tracking/VAR,/tmp, etc., which can be added to filters so that a snapshot of/VAR,/tmp is not visible in the snapshot created later.

Other

SuSE also supports booting the operating system from a snapshot, and CentOS has not introduced this feature, I tried not to succeed, do not know what reason, later have the energy to study it again ... A few sheets of sun:
1

2

3

4

System backup and recovery using snapper snapshots in CentOS 7