ChronShield and Timeshift are system restore utilities for Linux that create a snapshot of system files.
ChronShield creates system snapshots using BorgBackup.
Timeshift creates system snapshots using Rsync and BTRFS snapshots.
Feature Comparison
| Feature | ChronShield - BorgBackup | Timeshift - RSync | Timeshift - BTRFS |
|---|---|---|---|
| Compression | Snapshots are compressed with LZ4 or ZStd. Even at the fastest settings it can reduce disk usage by 60%. | Files are stored without compression and require a lot of disk space. | BTRFS supports compression at the filesystem level. Files in a snapshot have the same compression as the original file. |
| Deduplication | Files are de-duplicated by splitting data into blocks. Only new data blocks are added to repository when new snapshot is created. De-duplication works both between snapshots (same file in multiple snapshots) and within the same snapshot (similar files in same snapshot). | No de-duplication. A copy of entire file is stored again if there is any change in data or metadata (permissions, timestamps, etc). | BTRFS snapshots are ref-linked with the original subvolume which results in de-duplication between snapshots. Similar files within the same snapshot are not de-duplicated. De-duplication can be done manually by running special tools. |
| Disk space | If a 1 GB file has changed by 1 MB, creating a new snapshot will use only 1 MB of additional space. | If a 1 GB file has changed by 1 MB, creating a new snapshot creates another copy of the file which requires 1 GB of additional space. Files are hard-linked between snapshots to save disk space. but directories cannot be hard-linked in the same way as files. Duplication of the directory structure requires about 200 MB of disk space for each snapshot. | Creating a new snapshot does not require additional disk space since files in snapshot are ref-linked with original files in the system |
| Encryption | Snapshots are strongly encrypted with 256-bit AES encryption and can be accessed by providing the correct password. | Files are stored without encryption and can be accessed by anyone with root permission. | Files are stored without encryption and can be accessed by anyone with root permission. |
| Integrity | Checksums are calculated and stored for data blocks stored in the repository. Any damage or modification to snapshot data can be easily detected. | Files and directories are stored without additional checksums. Files can be modified by anyone with root permission. | Files and directories are stored without additional checksums. Files can be modified by anyone with root permission. |
| Filesystem Support (Snapshot location) | Snapshots can be saved to any location on any filesystem. | Snapshots can be saved on Linux filesystems that support hard-links (EXT4, BTRFS, etc) | Snapshots are saved on the same BTRFS filesystem |
| Filesystem Support (System disk) | Common Linux filesystems like EXT4, BTRFS, XFS, etc are supported.
ZFS is not supported. |
Common Linux filesystems like EXT4, BTRFS, XFS, etc are supported.
ZFS is not supported. |
BTRFS only. |
| Moving Snapshots | Snapshots are easy to copy or move. The folder containing snapshots can be copied or moved just like any other folder | Snapshots are difficult to copy or move due to the presence of hard-linked files between snapshots. | Snapshots are difficult to move and require special commands such as btrfs send and btrfs receive. |
| Format | Snapshots are stored in the Borg repository format and must be mounted as a FUSE filesystem to access the files and directories inside. | Files and directories in snapshots can be browsed with a file manager without any extra steps | Files and directories in snapshots can be browsed with a file manager without any extra steps |
| Online Snapshots | Snapshots can be created while the system is running/online. | Snapshots can be created while the system is running/online. | Snapshots can be created while the system is running/online.
Snapshots are atomic. It captures the current state of all files at the instant that the snapshot is created. |
| Online Restore | System cannot be restored while it is running/online since running processes can overwrite restored files.
Restore must be done offline by booting from a Live-USB. |
System can be restored while it is running/online but has a risk of failure since running processes can overwrite restored files.
Offline restore is recommended by booting from a Live-USB. |
System can be restored while it is running without any risk. The restored subvolume becomes active only after the next reboot.
Offline restore can also be done by booting from a Live-USB. |
| Free space management | Disk space required for a new snapshot can be estimated quickly due to the cache that BorgBackup maintains. | Disk space required for a new snapshot is difficult to estimate. Estimation requires almost as much time as creating the snapshot. | Creating a new snapshot does not require any disk space. However, disk space usage will increase over time when system files change, and files diverge from the original snapshot. |
| Bootloader Handling | Works with most bootloaders. Does not install, reinstall or make changes to bootloader configuration. Files on boot partition and ESP will be restored from snapshot.
On Fedora the GRUB configuration will be temporarily changed to complete the restore. |
Can reinstall GRUB2 bootloader. Other bootloaders are not supported. | Can reinstall GRUB2 bootloader. Other bootloaders are not supported. |
| Inode Pollution | Each snapshot appends data to existing files in data repository and creates few files. | Each snapshot duplicates the root directory structure, creating 50K directories and 300K hard-links on an average system. Repeated creation and deletion of hourly snapshots can use up inodes and fragment the filesystem metadata. | Each snapshot or subvolume is an independant filesystem tree with its own inode namespace. |
| User Configs | Config files in user’s home directory are always included in snapshots, and can be replaced on restore (optional). | Config files in user’s home directory can be included in snapshots (optional), and replaced on restore (optional). | Entire home subvolume (@home) can be restored or excluded. It is not possible to restore or exclude only config files. |
| Scheduling | Scheduled snapshots are created at hourly intervals. Intervals of 1/2/4/6/8/12 hours can be selected. | Scheduled snapshots are created at hourly intervals if enabled. | Scheduled snapshots are created at hourly intervals if enabled. |
| Speed | Creation of snapshot is very quick (less than a minute) due to the cache that BorgBackup maintains. | Creation of snapshot is quick but can take some time since files and directories need to be compared. | Creation of snapshot takes less than a second since it does not require files to be compared or copied. Only subvolume metadata is duplicated. |
| Excluded Items | Temporary directories, cache directories, external filesystems, and dynamically-populated system directories are excluded from snapshots. | Temporary directories, cache directories, and dynamically-populated system directories are excluded from snapshots.
External filesystems must be excluded manually by user if mounted in non-standard locations (outside of /media, /run, etc) |
Snapshot is created for entire subvolume.
External filesystems and nested subvolumes are excluded. |
| Flatpak Packages | Flatpak packages are excluded from snapshots to save disk space.
Data and settings are included in snapshots and can be replaced on restore (optional). |
Flatpak packages are included in snapshots.
Data and settings can be included in snapshots and replaced on restore (optional). |
Flatpak packages, data and settings are included in snapshots. |
| Snap Packages | Snap packages are excluded from snapshots to save disk space.
Data and settings are included in snapshots and can be replaced on restore (optional). |
Snap packages, data, and settings are excluded from snapshots to save disk space.
Data and settings can be included in snapshots and replaced on restore (optional). |
Snap packages, data and settings are included in snapshots. |
| Virt-Manager, VirtualBox, Docker | Data and settings are excluded from snapshots to save disk space. | Data and settings are excluded from snapshots to save disk space. | Data and settings are included in snapshots. |
| Fedora Support | Fedora and SELinux is supported (for GRUB bootloader only) | Not designed for Fedora.
Restored system can fail to boot due to SELinux restrictions. |
Not designed for Fedora.
Restored system can fail to boot due to SELinux restrictions. |
| Hardware failure, filesystem errors, disk reformatting | System disk must be healthy for restore to succeed. Restore will not work if the system disk is damaged or reformatted. | System disk must be healthy for restore to succeed. Restore will not work if the system disk is damaged or reformatted.
Has an option to remap the target devices to new devices, but this has a chance of failure. |
System disk must be healthy for restore to succeed. Restore will not work if the system disk is damaged or reformatted. |
| SecureBoot | SecureBoot is not supported. | SecureBoot is not supported. | SecureBoot is not supported. |
This is a comparison of how system snapshots work as implemented by ChronShield and Timeshift. This is not meant to be a comparison of Rsync and BorgBackup. RSync is a file transfer tool while BorgBackup is a file backup tool. Both tools are very versatile and have their own advantages and disadvantages.
Excluded items remain unchanged after restoring a snapshot. This is both a pro and a con. Restoring a snapshot will keep the current state of excluded items (pro), but this means that you won’t be able to rollback any undesired changes (con).