As previously seen in the course, testing our backup scripts requires three major steps: restoring your backup, performing integrity tests and analyzing the logs.
Let’s start with the first step!
Restore Your Backup
When you need to restore one or more files, you can list the available Restic snapshots and choose one to restore by date.
View your available snapshots by running the following command, remembering to replace the mount point to match your own:
restic -r /media/nkendrick/USB-STICK/backups snapshots
There are four snapshots in the image below, each with a unique ID at the beginning of the line. Once you have noted the one you want to restore, use Restic to get it back.
The highlighted snapshot 5cf13751 was restored using the command below; this restores it to a temporary location in the current folder (./) called /testrestore so it can be checked and the required file/s put back in the right place:
restic -r /media/nkendrick/USB-STICK/backups restore 5cf13751 --target ./testrestore
Let’s see how to restore a snapshot from your own repository to a temporary location on your Linux machine in the video below:
Perform Integrity Tests on the Results
Now that we have restored a snapshot of the syslog files, we can check whether the contents of the live file match the current one in /var/log. Let’s see how in the video below:
To compare the live and restored syslog files, we need to use the Linux diff command:
diff --brief /var/log/syslog ./testrestore/var/log/syslog
Not surprisingly, the live and restored syslog files probably differ. Don’t panic; this is because the live syslog file is being updated all the time, and it’s changed since the backup was made.
When log files start to get larger than a defined size, they are compressed and set aside as numbered archives, creating a new live file. The oldest archive file is eventually deleted.
In the video, we tried a diff command on archive file number 4, and no output was returned, which means the two files compared were identical. If you have archived syslog files, try running a diff command on one, comparing it with the live copy; unless a lot of time has passed since the original backup was taken, the older archives should be identical.
Analyze the Logs
We have now covered the basics of using Restic with a cron script. You learned how to analyze the snapshot logs and create your own log files for keeping an eye on things.
Monitoring the logs will allow us to check for any errors or anomalies that need attention. It will also enable us to check the size of backups and whether we need to make adjustments to available storage or the type and frequency of backups. For example, this log has errors about the backup repository’s location being full:
If your Linux system has a graphical user interface, which it almost certainly will unless it’s a dedicated server, then you can use your file manager to navigate to a log file and then open it into any text editor, such as Geany or Gedit. If you are comfortable working on the command line, you could use native editors such as nano or Vim or just display the contents using the less command, which is ideal for scrolling and searching through text files.
Remember, though, that the log files are being created by default in the root’s home folder. So if you are logged in as a non-root user, you will not be able to access them unless you edit the backup script and have the log files written to a user-accessible folder and the file’s rights changed to allow non-root access. This information is not covered here because usually only the system administrator (root) needs to see the backup log files.
To see the log files (as root), try the following:
Enter the command
sudo su -and then your user’s password to enter root mode.
Doing this should also place you in the root’s home folder, where there will be at least one .log file.
List the log files with
ls *.logPick a log file and type the command less
logfilename.logScroll up/down through the file to examine its contents.
To find a specific text pattern, type
/pattern (example: /error)and press ENTER. Note that the command is case-sensitive.Pressing / ENTER will jump to the next occurrence.
Press q to quit less.
There's a good summary of the less commands here.
In the video below, you’ll see how to analyze your logs and do some simple checks:
Let’s Recap!
Testing scripts and making sure that they do what’s expected should be part of every script development plan, especially if they are designed to help reduce the impact of unexpected data loss!
Similar to Windows, Linux has a script scheduler called cron.
We can “pipe” the output of commands to, for example, create a log file.
Performing test restores and checking logs is always part of a good backup scheme.
Scripts, snapshots, repositories, logs, cron jobs; we’re really getting on top of Restic! There’s this thing called “the cloud,” and you’ve probably heard about it! Restic knows about cloud backups, so let’s set one up and test it!
