Shoot is a backup solution to backup files on one UNIX or UNIX alike machine and transport the files over the internet through a secure channel to another UNIX or UNIX alike machine.

This document will explain more of the technical inside bits and pieces of Shoot.

This document will explain:

Shoot consists of three scripts working together:
This script checks to see if the server is ready to start and will actually start the server script It keeps track of the server process. is the script which makes the backup, will calculate if there's enough space etc.
This script runs on the client machine and it will fetch the files from the server, that is:

The three scripts are working together, providing:

This document tries to give insight in the scripts used. However to fully understand Shoot, you better dive into the scripts as well, we try to keep them documented well.

First we start by looking at the server side with the script and how it interacts with the script.
The script will first do some sanity checks, like checking if there are config files, if the previous run of the server process ended in a clean state. It will then write its own state to the subsystem file (server.status) and start the script.

The script will do some sanity checks as well, like if there are config files, etc. Also, it will check if there are already existing backup files and a server.status file. If these are not available it will assume it is a first run, and it will skip some checks.
Next it will check if there's enough free space on the filesystem where the backupfile will be placed. Then it will check if there are new files to backup. If there aren't, there's ofcourse no use to make a new backup, the previous backupfile will suffice.
If a new backupfile is to be made, it will do so, and it will write its MD5 sum to disk.
The last real thing it does is remove one of the old backup files. After that it will do some cleanup of tempfiles.

Every error or message which occurs, is written to the server.status file. This is also done by the script. These error codes can be:

The difference is quite simple:
A fatal error should not occur in the first place, whereby a message has the meaning of telling that everything is ok, and that the next step in the process can be done.

If for some reason the script breaks, the script knows what happened last, and will be able to mail you about it. There are currently 3 error codes that mean good news, that's 4, 9 and 30. Please read the errorcode_readme.txt for more information about the meaning of the error codes.

As you may expect, the first thing the client process will do is fetching the server.status file by using rsync. If the client succeeds in doing this we know that:

This check is not enough, because we don't know when the server did its last run, so the client will check the timestamp of the server.status file. If this file is older then one day (giving the declaration that the server runs every day) the client will bail out with an error message. If the server did not end in a clean state with one of the golden error codes (4, 9, 30) then it will also decide to do nothing.
If the file is less then one day old and there are no fatal errors, the client process will check for enough free space and then fetch the backupfile, together with the file that holds the MD5 sums. After that it will check the MD5 sums, and remove one of the old backup files.

By running these scripts from the cron daemon you will be able to receive mail with the output of the server and client processes. By providing an internal mail system it will even be possible to send mail from hosts that have no mailclient or server installed.