Shoot is a backup solution, where backups can be stored on a remote machine, so that your backup is safe, and even if your house burns down, or some other disaster may happen, your data will be somewhere else, even if this a a thousand kilometers away.
This document will tell you under what license it is released, and it will explain how to configure Shoot to end up with a reliable backup solution.
Before we dive into the steps how to configure this, we must mention our license policy and of course the stuff how to use it, like a disclaimer.
Shoot is Copyright 2003-2005
Marcel Pol (mpol at gmx.net)
Edwin Schokkenbroek (edwin at spacebugs.nl)
Shoot program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
For the complete license use this link: Full GPL license
After this official part, let's go to the next step and get our hands dirty by the configuration process of Shoot.
Next Go to TOPBefore we actually configure SSH, you now may decide which machines are going to talk to each other. This may be two machines in your network or two machines connected by the internet on a 24/7 basis.
One machine will be your SSH server and one machine the SSH client.
The SSH server is the machine where your SSHD process (the ssh daemon) is running.
By choosing the machines use this check list:
To complete this step, you must have SSH installed.
This is a very imported step in the whole configuration process. If for some reason, you dont't get this working, you can skip all next steps and you're done till you manage to fix this.
From my own experience, if this is not working, start to check two things:
The first step is create an account on the client machine let's say shoot. After creating the account go to his directory and dive into the .ssh directory.
Give the following commands:
username@client$ cd $HOME
username@client$ cd .ssh
username@client$ ssh-keygen -f id_rsa -t rsa
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_rsa.
Your public key has been saved in id_rsa.pub.
The key fingerprint is:
c3:af:e9:6c:2f:19:4d:b5:1a:a9:40:06:54:e6:60:08 vpn@localhost
Next copy this file to the server machine:
username@client$ ssh username@server 'mkdir .ssh'
password: (type password for username@server)
username@client$ scp ~/identity-test/id_rsa.pub username@server:.ssh/authorized_keys
password: (type password for username@server again)
Logon to your SSH server and fix your rights:
username@server$ cd $HOME
username@server$ chmod go-w .
username@server$ cd $HOME/.ssh
username@server$ chmod 700 .
username@server$ chmod 600 *
After this you could ssh from your SSH client to your SSH server without needing to enter the password by doing:
username@client$ ssh username@server
If this works do the same but make your client server and vica versa.
For a full overview on this see: Hacking Linux exposed
These steps are for the machine where you want to backup your files, the server. The backup process consists of the following steps:
You must decide on which file system your backup files get stored, and this machine itself will possibly be a client to, so you must have the same huge filesystem. Or pick another large filesystem.
Let's say we have a file system /home which is large enough. And for the client storage we choose another filesystem mounted under /net_backup You should do the following:
username@server$ cd /home
And put your files in the home dir of the created account shoot:
username@server$ cd shoot
username@server$ mkdir backup
In this dir the backup files are stored.
On the server side you need to edit the server.conf file
This configuration file is straight forward:
#############################
# config file for shoot.sh #
#############################
# File wich holds dir to backup
DIR_LIST="shoot_list"
# name of the current cpio file
CPIO_NAME="username.cpio"
# filename for the md5sum file
MD5_FILE="md5sums.txt"
# Number of oldest backups to keep
NR_BACKUP=2
# Where to store the log file
LOGFILE="/var/log/shoot.log-$CURRENT_DATE"
# Place to store the backup file(s)
BACKUP_DIR="/home/shoot/backup/"
SRV_STATUS="server.status"
SCRIPT_DIR="/home/shoot/"
SEND_MAIL="NO"
These are the options you want to change to reflect your situation. There are a couple other options you can configure, mostly these options have to do with file names for temp files.
Short explanation of options:
DIR_LIST = Here you give the file name of the file where all your dirs are stored to backup,Decide which directories you want to backup. For example you want to backup:
/etc/Shoot will work from a cron job, so at the server you should add a line as following into your crontab:
# Backup server script
## /usr/bin/shoot_status.sh
00 4 * * * /usr/bin/shoot_status.sh
This means that every night at 4 o'clock shoot_status.sh will be started.
Running the server for the first time requires some manual intervention. We are planning to fix this in the upcoming 1.3 release, but for now we'll have to live with it. The first thing to do after installing and configuring the server, is to generate a server.status file by running the serverscript as:
username@server$ shoot_status.sh -force
The second issue that a new setup will run into is the number of backups to keep.
A daily running server will generate a new backupfile, and remove one of the old
backupfiles. If in the server.conf the NR_BACKUP is set to 2, it will expect to
start with 2 backup files and end with 2 backup files. If this number is not the
same as the number of backup files on disk, it will generate a fatal error, which
will make the clientscript to bail out.
The easy way to work around this is to touch a few files with older dates. For
example, the current date is 9 October 2005, and your NR_BACKUP is set to 2.
You can then run the following command:
username@server$ touch username.20051007.cpio username.20051008.cpio
Then when you run the serverscript by hand, it will generate a file called username.20051009.cpio and remove the old "backup file" username.20051006.cpio. This way you will be sure that the serverscript will write an errorcode that claims success, which will make the client process run without bailing out.
These steps are for the machine where you want to store your backup files.
The client process consists of the following steps:
You must decide on which file system your backup file get stored, and this machine itself will possibly be a server to, so you must have the same huge filesystem. Or pick another large filesystem.
Let's say we have a file system /home which is large enough. And for the client storage we choose another filesystem mounted under /net_backup You should do the following:
username@client$ cd /home
(And put your files in the home dir of the created account shoot :)
username@client$ cd shoot
username@client$ mkdir backup
In this dir the backup files are stored.
On the client side you need to edit the client.conf file.
This configuration file is straight forward. The options to set on the client side are:
SSH_PORT="22"
SSH_USER="user@yourdomain.extension" # Username for connection,
SSH_PUB_KEY="/home/shoot/identity-test/id_rsa" # Pub key for ssh conection,
REMOTE_PATH="/home/shoot/" # Remote path for uploading files,
DIR_LIST="shoot_list" # File wich holds dir to backup,
TMP_FILE="tmp_file.lst" # which temp file to use,
TMP_FILE_BCK="tmp_file_bck.lst"
CPIO_NAME="username.cpio" # name of the current cpio file,
MD5_FILE="md5sums.txt" # filename for the md5sum file,
MD5_FILE_TMP="md5sums.tmp"
NR_BACKUP=2 # Number of oldest backups to keep,
LOGFILE="/var/log/shoot.log-$CURRENT_DATE" # Where to store the log,
BACKUP_DIR="/home/shoot/backup/" # Place to store the backup file(s),
SRV_STATUS="server.status" # Name of the server status file,
SEND_MAIL="YES" # Use builtin Mail function.
The only options you perhaps want to change is:
SSH_PORT="22" # SSH port to use,
SSH_USER="user@yourdomain.extension" # Username for connection,
SSH_PUB_KEY="Path to your identity file" # Pub key for ssh connection,
REMOTE_PATH="/home/shoot/" # Remote path for uploading files,
CPIO_NAME="username.cpio" # name of the current cpio file,
NR_BACKUP=2 # Number of oldest backups to keep,
BACKUP_DIR="/home/shoot/backup/" # Place to store the backup file(s).
A short explanation of the option you want to set:
SSH_PORT = You can specify a different port number for SSH to use when connecting to the SSH server. For example, if you have a firewall running NAT and port forwarding, this options allows you to use a different port number,Shoot will work from a cron job, so at the client you should add a line as following into your crontab:
# Backup client script
## /usr/bin/client_shoot_cpio.sh
00 5 * * * /usr/bin/client_shoot_cpio.sh
This means that every night at 5 o'clock client_shoot_cpio.sh will be started. When sheduling Shoot on the client side, be sure not to set the time too short. Meaning: If your server process is running, you don't want the client to fetch the cpio file. This might break your backup. Having an hour (depending on the size) of time between the server and client process should mostly be enough.
On some platforms you must do some extra installation. For example on SLACKWARE 8.0 stat is not always installed.
On SLACKWARE 8.0 stat is not always installed. You must get the core-utils package, untar and this. Go to the package directory:
$ ./configure
$ make
Copy the stat file to /usr/bin:
$ cd src
$ cp stat /usr/bin