How to Set Up an Ultimate Backup System, Using Duplicity, Systemd and Thunar on Arch Linux Part Three

How to Setup Automated Duplicity Backups for the User: 

Now that we have set the automated backups for the system, it is time to do the same for the user. The process is similar with some minor modifications. First things first, we need an operation folder where we will place all of the duplicity related files. Create the following folder:

mkdir /home/my_user/.config/duplicity_backup

In order to simplify our life when we are implementing the front end, we will not place all of the duplicity parameters into one file. Create the following file:

vim /home/my_user/.config/duplicity_backup/exclude_list.txt 

This file will contain the list of files and folders that should be excluded from backup. It should be filled in similar to this:

Note that Music, Videos and Pictures are excluded in this case, this is done to conserve space on the remote server. Fill free to include those folders, by removing them from the list.  Now we need to specify the remote repository where the files will be stored:

cd /home/my_user/.config/duplicity_backup/ 
echo "scp://my_user@server///home/my_user/repos/me" > repo_location

 Finally we need to create the backup scripts:

vim back_home_up.sh

with the following content:

Make this script executable and run it:

chmod +x back_home_up.sh
back_home_up.sh

Now you should have your first full backup of home folder on the remote repository. It is time to set up user units for systemd to automate it. Navigate to the ~/.config/systemd/user folder, if it is not there create it. Than create duplicity-remote-backup.service and duplicity-remote-backup.timer

files with the following content:


Now enable the timer by executing:

systemctl --user enable duplicity-remote-backup.timer

This shall conclude the back-end of the duplicity backup system for the user. Next we will discuss the front-end.

How to Implement a Front-end to Duplicity for Thunar, Using thunarx-python:

Thunarx-python provides python bindings for the Thunar Extension Framework. We will be using it to implement a Thunar plugin that provides a submeny with restore options. To install it on Arch Linux you either need to download it from AUR and install it manually or run the following command: 

yaourt thunarx-python

Once the installation is complete, create the following file:

sudo vim /usr/share/thunarx-python/extensions/thunarx-submenu-plugin.py 

with this content: 

Don't forget to edit line 12 and set the dup_folder to the correct location. This will add the submenu option "Restore"  to Thunar when you right click on a file. For this to work you need to add one more additional file to   /usr/local/lib/python2.7 . Execute the following commands in command line:

cd /usr/local/lib/python2.7 
sudo vim dupController.py

and fill it in with:

Now you should have it all up and running, test it by restoring and arbitrary file.

How to Set Up an Ultimate Backup System, Using Duplicity, Systemd and Thunar on Arch Linux Part Two

 

How to Automate Script Calls Using Systemd:

How to Write Systemd Service Units:

Now that we have a working script for performing a system backup, we want to automate it. To get familiarized with systemd I would recommend to read through the wiki pages of arch Linux they are pretty great [1], [2], [3]. The back_sys_up.sh is responsible for backing up the system, independent of any users. That is why we want it to run whenever the machine is powered, and not depend on whether the user is logged in or not. To do so we need to create our service for calling the backup script in  /etc/systemd/system folder:

cd  /etc/systemd/systemsudo 
sudo vim duplicity-system-remote-backup.service

This file must contain the following content:

It is also recommended to find out which services are responsible for the network connection on your machine and add the requirements in this file at the bottom of the [Unit] section:

Requires=your_network_connection.service 
After=yout_network_connection.service

This will ensure that your machine is connected to the network before running the backup service. The [Unit] section contains all of the parameters responsible for the systemd unit, and it is universal for all the systemd units. In our case we just have a short description of what the unit does and its requirements. The [Service] section is unique for systemd service units. We have only two parameters here. Type specifies the type of the service in our case oneshot, which means that the service will stop upon the completion of the script. Since we are going to be using a timer to activate the script every time this is a desired behavior.  The second parameter is the ExecStart, which specifies the script to be executed.

How to Write Systemd Timer Units:

Now lets configure the timer for our service. To do so execute the following command:

sudo vim duplicity-system-remote-backup.timer

It is important that the timer and the service files have the same name. The content of the timer should be as follows:

Here there are two important parameters. OnBootSec specifies the time that should pass after boot in order for the service to start, in this case 5 minutes. OnUnitActiveSec specifies the time that should pass from the last time the unit was active in order to start the service, in this case 1 hour. Now it is time to enable the timer and do some testing. Run the following command to enable the timer:

sudo systemctl enable duplicity-system-remote-backup.timer

In order to test you need to restart. After reboot open two terminal windows. In one of them type:

 journalctl -f

Leave this terminal visible, here you can monitor all the systemd activities. In the second terminal you can type:

systemctl list-timers 

 To see which timers are currently present, how much time is left until they execute, when was the list time they have been active, etc.

Housekeeping:

Since full backups can take a long time on slow networks, and since there is no guaranty that your machine will stay up for the duration of this time, duplicity allows the restarting of interrupted backup processes from the point of interruption. To do so duplicity divides the bulk of your files into blocks and uploads them block by block. Every time a block is being uploaded a lock file is being created by duplicity. This can cause issues when duplicity is unexpectedly interrupted, i.e. the machine is turned off while duplicity is performing a backup, or something along this lines. The problem is that after reboot the lock file is still in place, and duplicity will refuse to perform backups if there is a lock file from another instance. To overcome this issue a small script must be written that will be activated every time after boot, and that will look for the lock files and delete them before duplicity is activated. To do so create the following file:

sudo vim /root/scripts/system_backup/remove_locks.sh

and fill it in as follows:

In order to save time I took a shortcut and also added the remove functionality for the my_user in to this script as well. By default the lock files are stored in ~/.cache/duplicity folder. If you did not explicitly specify a different folder this script should do the trick. To automate this process we need to create the systemd service and timer units for this script. To do so create duplicity-cleanup-onboot.service  duplicity-cleanup-onboot.timer  files in /etc/systemd/system/ folder, with the following content:

Now you should have s fully functioning system backup using duplicity. In the next part we will describe the creation of the back-end as well as the front-end for the backup system of the user.

How to Set Up an Ultimate Backup System, Using Duplicity, Systemd and Thunar on Arch Linux Part One

 

Introduction:

In this multi-step tutorial we will discuss how to set up a complete backup system on your freshly installed arch linux. We will be using duplicity as a backup program, which will perform automatic backups of your system to a remote server. To automate the backup process, we will use systemd units and timers. Once the back-end is set, we'll implement a front-end GUI that is integrated with Thunar file browser to make the restoring of backed up files more comfortable and user friendly. 

List of tools:

Back-end: 

• Backup program: Duplicity
• Backup automation:  Systemd units and timers
• Scripting: Shell

Front-end:

• File browser: Thunar
• Plugin API: Thunarx-python
• Scripting: Python 2.7

Installing  Duplicity and Configuring ssh on the Client Side:

Installing duplicity on arch linux is pretty straight forward. Execute the following command:

sudo pacman -Syu duplicity

Enter your password, seat back and relax. Once the installation is complete it is time to configure the remote repository. We will be using ssh for transferring the files between the server and the local machine. There is a number of tutorials and how-toes on the internet describing how to properly set up ssh access on a remote server, thus I will omit detailed descriptions and will only concentrate on the basic configurations on the client side. 

 We will split the backup system into two parts. First part will be running on the system level, and be responsible for backing up your system files such as /var, /usr, /boot, etc. The second part will be running on the user level and will be responsible for backing up user files i.e. /home/USER.   

Preparing system level backups:

How to Configure SSH for automated remote login: 

First things first, you need to write/configure ssh config file for the root user. If you do not have the file already you need to create /root/.ssh/config to do so type:

sudo vim /root/.ssh/config

Inside of this file you need to add the following content:
Where my_domain.me should be replaced by the domain name or the ip address of your server. Note, that it can also be a server in your local network described by the local ip address. The important thing is that the server should be accessible from your machine.  In this example we are using port 22 since it is the default ssh port. For security reasons it is recommended to set the port to a higher number. This can be done by editing /etc/ssh/sshd_config  on your server and changing the .ssh/config Port parameter correspondingly.

Next you need to generate a pair of public and local keys for secure ssh access to the server. To do so type the following in the command line:

sudo ssh-keygen

Answer all of the question correctly. When promoted to enter a password  leave it blank, otherwise you will not be able to automate the ssh login to the remote server. Next you need to copy your public key to your server, to do so type:

sudo ssh-copy-id server

Once you type in your sudo password followed by your my_user password on the remote server your public key will be copied. To test if your password-less ssh login works type the following into the command line:

sudo ssh server

now you should be logged in your remote server as my_user.  Type exit to return to your local machine.  Now that the automated ssh login is configured for the root user, you need to configure it for the regular user as well. Perform all of the actions in this sub-chapter without the using sudo in front.

How to set up Duplicity:

Now it is time to set up duplicity to perform backups to the remote server. First of all you will need a folder on the remote server where duplicity will store its files. Since we are planning to split the backup process into two subsystems we will create two folders. One for system backups and one for user backups. Type the following in to the command line:

ssh server 

mkdir /home/my_user/repos/system 

mkdir /home/my_user/repos/me 

 lets write the backup scripts for the system backup first. Create a folder in the home directory of your root to store all of the duplicity related stuff.

sudo mkdir /root/scripts/system_backup 

vim /root/scripts/system_backup/back_sys_up.sh 

Now fill in the following content:
Duplicity is highly configurable, and there are many options that can be set. We will discuss a few of them here for more information please refer to [1] and [2]. Due to a minor bug in the current version of duplicity (0.7.09) there are some issues with gpg encryption for the root user. When testing I discovered that duplicity fails to fetch the gpg key if the last backup session has been interrupted, thus the usage of --no-encryption option. If you are using a later version of duplicity or want to tackle the problem on your own, I would refer you to [3] for more information on how to set up encryption on the remote server. Duplicity can perform two types of backup full or incremental. Full backups are the full backups of the not excluded folders and files, where as the incremental backups track the changes in the files and folders from last full backup. Incremental backups are small and fast. They put less strain on your network, but in order to restore a file from a backup multiple multiple incremental backups must be downloaded along side with the full backup in order to reconstruct the file. This means that the longer the chain of incremental backups the longer it takes to reconstruct the file. Therefore it makes sense to force a full backup once in a while.  --full-if-older-than 15D forces duplicity to perform a full backup every 15 days.

Run the following command in order to create your first full backup:

sudo chmod +x /root/scripts/system_backup/back_sys_up.sh 

sudo /root/scripts/system_backup/back_sys_up.sh 

Now you are done with the first part of this tutorial. We will be discussing the automation process in the next part.