Timeshift is promoted as a way to recover files for a broken system. Some people use it to backup their user directory. From everything I read, Timeshift expects you to install Linux first then use Timeshift to recover configuration files and software packages. I use Timeshift to backup the system and, luckily, have not needed it to recover anything.
Timeshift does not backup all the system level files. As an example, the /dev directory is not backed up. Some files should be excluded because they are built at boot time and discarded after use. You have to search through the settings to work out what is excluded. Just use the defaults.
Backintime is a similar program for your home directory. I will mention the main differences later.
- Similar programs
- Processing time
- Space used
- Timeshift backup file structure
- What does Timeshift copy and not copy?
- Notes on odd directories
- The settings file
Similar programs
Timeshift uses rsync in the background and there are a dozen other programs using rsync in the background. Outside of the rsync usage, Timeshift can be compared to the System Restore program in Windows, BackInTime (https://github.com/bit-team/backintime), the unmaintained TimeVault, and Time Machine (Mac OS only).
Timeshift is easier to use than System Restore. Both require understanding to make a restore work. Timeshift can backup system files in an easy to investigate form while System Restore is difficult to read or check. Both require a working system for any type of restore. For Linux, you keep a bootable USB stick ready to restore Linux then boot the Linux to run the Timeshift restore.
Backintime for your home directory
Backintime works, internally, the same way as Timeshift with rsync creating snapshots from Ext4 to Ext4. The default settings in Backintime handle your home directory, not system files.
Backintime can backup to NTFS and other file systems but you will not get the space saving feature of Ext4 as other file systems do not have an equivalent to the Ext4 inode system.
Backintime lets you set up multiple profiles for different backups. You can use the default profile for your daily backup and set up another profile for a weekly backup to a different backup disk. You might then add a monthly backup to a third disk.
Processing time
Timeshift backs up from a Linux Ext4 partition to an Ext4 partition. Ext4 has a feature called inodes separating files from directory entries. When Timeshift creates several backups, called snapshots, the rsync part copies only new files and changed files. Unchanged files have only a directory entry created with the entry pointing to the same inode as the original file entry. Two snapshots, two directory entries, but only one file, no duplicates. The first snapshot is slow. The next ones are fast.
Assuming all your Timeshift backups are to the same Ext4 partition on a good quality fast USB stick, the first one might be 40 minutes and the rest just 4 minutes. My Sandisk Extreme Pro and Samsung top of the line USB sticks can do that first snapshot in 40 minutes. My SSDs in USB 3.1 and 3.2 enclosures can do it in 20 minutes. Some people report their USB sticks used 12 hours.
Space used
The space saving feature of Ext4 produces significant results. I run Timeshift on a desktop computer using an old 64 GB SSD as the target disk. Today there were five snapshots. The following table shows the properties of each snapshot. The total space used adds up to 87.1 GB, more than all the space used on the disk, but the actual space used is only 24 GB. The Ext4 file system is a huge space saver in this case.
| Files | Space used in Gigabytes |
| 418,812 | 17.0 |
| 454,749 | 17.0 |
| 454,670 | 17.4 |
| 454,673 | 17.4 |
| 454,708 | 17.4 |
Timeshift backup file structure
Timeshift creates the following file structure in the backup.
timeshiftsnapshots 2018-01-23_20-10-40 localhost /bin : etc : exclude.list info.json rsync-log.gz rsync-log-changes 2018-02-13_15-42-22 snapshots-boot snapshots-daily snapshots-hourly snapshots-monthly snapshots-ondemand 2018-01-23_20-10-40 (These are links ) 2018-02-13_15-42-22 ( to the backup in snapshots.) snapshots-weekly
exclude.list
Exclude.list contains many lines similar to the following.
/dev/* /proc/* /sys/* /media/* /mnt/* /tmp/* /run/* /var/run/* /var/lock/* /root/.mozilla/firefox/*.default/Cache
info.json
info.json is similar to the following.
{
"created" : "1516698640",
"sys-uuid" : "49af5bf1-77b5-4282-add0-ee9a34a20201",
"sys-distro" : "LinuxMint 18.3 (sylvia)",
"app-version" : "17.11",
"file_count" : "706395",
"tags" : "ondemand",
"comments" : "",
"live" : "false",
"type" : "rsync"
}
rsync-log.gz
rsync-log.gz contains rsync-log compressed. rsync-log contains something like the following.
2018/01/23 20:10:40 [7793] building file list 2018/01/23 20:10:40 [7793] .d..t...... ./ 2018/01/23 20:10:40 [7793] >f+++++++++ core 2018/01/23 20:10:40 [7793] cL+++++++++ initrd.img -> boot/initrd.img-4.13.0-26-generic 2018/01/23 20:10:40 [7793] cL+++++++++ initrd.img.old -> boot/initrd.img-4.10.0-42-generic 2018/01/23 20:10:40 [7793] >f+++++++++ tmp\Activation.log 2018/01/23 20:10:40 [7793] cL+++++++++ vmlinuz -> boot/vmlinuz-4.13.0-26-generic 2018/01/23 20:10:40 [7793] cL+++++++++ vmlinuz.old -> boot/vmlinuz-4.10.0-42-generic 2018/01/23 20:10:40 [7793] cd+++++++++ bin/ 2018/01/23 20:10:40 [7793] >f+++++++++ bin/archdetect 2018/01/23 20:10:40 [7793] >f+++++++++ bin/bash
rsync-log-changes
In the first backup of a series, rsync-log-changes contains something like the following. The only difference from rsync-log is the missing first line. The similarity happens because this is the first backup and every file is a change
2018/01/23 20:10:40 [7793] .d..t...... ./ 2018/01/23 20:10:40 [7793] >f+++++++++ core 2018/01/23 20:10:40 [7793] cL+++++++++ initrd.img -> boot/initrd.img-4.13.0-26-generic 2018/01/23 20:10:40 [7793] cL+++++++++ initrd.img.old -> boot/initrd.img-4.10.0-42-generic 2018/01/23 20:10:40 [7793] >f+++++++++ tmp\Activation.log 2018/01/23 20:10:40 [7793] cL+++++++++ vmlinuz -> boot/vmlinuz-4.13.0-26-generic 2018/01/23 20:10:40 [7793] cL+++++++++ vmlinuz.old -> boot/vmlinuz-4.10.0-42-generic 2018/01/23 20:10:40 [7793] cd+++++++++ bin/ 2018/01/23 20:10:40 [7793] >f+++++++++ bin/archdetect 2018/01/23 20:10:40 [7793] >f+++++++++ bin/bash
In the second and subsequent snapshots in a series, the rsync-log-changes file is smaller because it has only the changes. The file from the second backup looks like the following example. Notice that bin/archdetect and other files are not listed which means they are not changed.
2018/02/13 15:42:22 [3806] .d..t...... ./ 2018/02/13 15:42:23 [3806] >f.st...... core 2018/02/13 15:42:23 [3806] cLc.t...... initrd.img -> boot/initrd.img-4.13.0-32-generic 2018/02/13 15:42:23 [3806] cLc.t...... initrd.img.old -> boot/initrd.img-4.13.0-31-generic 2018/02/13 15:42:23 [3806] cLc.t...... vmlinuz -> boot/vmlinuz-4.13.0-32-generic 2018/02/13 15:42:23 [3806] cLc.t...... vmlinuz.old -> boot/vmlinuz-4.13.0-31-generic 2018/02/13 15:42:23 [3806] cd..t...... bin/ 2018/02/13 15:42:23 [3806] >f..t...... bin/journalctl
What does Timeshift copy and not copy?
Directories copied
The following directories were copied with what looks like no changes.
|
Directory |
Contains |
Notes |
|
bin |
176 |
No subdirectories. |
|
boot |
24 |
Contains grub and kernels. Clean this up if there are many kernels. |
|
home |
1 |
Just my user directory. |
|
lib |
30 |
Bunch of OS files. |
|
lib64 |
1 |
Link to other file. |
|
opt |
5 |
A few config files for applications. |
|
sbin |
293 |
Command line applications including fdisk. |
|
usr |
8 |
Mixed pile including Linux headers. |
|
var |
12 |
Another mixture of useful and junk data. |
Directories empty
|
Directory |
Contains |
Reason |
|
cdrom |
0 |
No CD drive |
|
mnt |
0 |
Nothing mounted |
|
root |
? |
Root is an unreadable link to nowhere. |
|
srv |
0 |
Unused. |
Directories not copied
|
Directory |
Contains |
Copied |
Reason |
|
/dev |
210 |
0 |
|
|
etc |
275 |
274 |
|
|
media |
1 |
0 |
The only thing in media is the backup disk |
|
proc |
246 |
0 |
|
|
run |
47 |
0 |
|
|
sys |
11 |
0 |
|
|
tmp |
14 |
0 |
|
Files copied
core
initrd.img
tmp\Activation.log
vmlinuz
vmlinuz.old
Notes on odd directories
/dev
/dev contains essential device files. They are not backed up by Timeshift. If there is a problem with a missing file, you have to build the file through a reinstall. Timeshift appears to expect you to install Linux first when you restore to different hardware.
/srv is a directory set up by someone to serve data through things like Web servers. Many services use a subdirectory in /var. When you are developing Web sites, you can use a subdirectory in your home directory so that all the server data is backed up with all your other project data. /srv has no use on any of my machines.
The settings file
Timeshift has a configuration file named /etc/timeshift.json and another named /etc/default/timeshift.json. Timeshift appears to copy the default file as /etc/timeshift.json then update the new file. /etc/timeshift.json contains your settings and the id of the most recent backup disk.
/var/lib/dpkg/info contains timeshift.conffiles, timeshift.list, and timeshift.md5sums. timeshift.conffiles points to /etc/default/timeshift.json. timeshift.list has a long list of directories and files used in the installation. timeshift.md5sums contains the MD5 checksums for all the Timeshift files installed in the system.
/var/log/timeshift contains logs from backups. /tmp/timeshift contains some unknown files. /usr/bin/ contains some Timeshift binary files.
/usr/share/ contains Timeshift icons, appdata, an applications file, locale files, a doc file, images, and other things but nothing about the current configuration.
- Log in to post comments