I started playing around with s3cmd command line utility and I realize that is really powerful so, I decide to write my own scripts to be able to backup automatically all the important files of my servers to the cheaper and easy to use Amazon S3 service.

The whole system is based on two bash scripts, the crontab and a few extra applications like 7zip and s3cmd. I will explain step by step how I build up the system and at the end I’ll provide the full code of the scripts.

Requirements

The first step is to be sure that you have installed the 7zip and s3cmd tools, in my case I’m using ubuntu so, for me the command to install the tools is:

sudo apt-get install p7zip s3cmd

Basic setup

Now we can follow with the basic setup, I created a folder in the root of the filesystem called backups, the inside this folder I create serveral folders, at the end the structure is like follow:

/backups
    /compressed
    /data
        /db
        /svn
        /www
    /scripts

The compressed folder is used at the end of the script to compress all the files to one .7z file, in the data folder we will copy the information we want to backup and in the scripts folder we will store as it’s name says the two scripts we will use.

Backup script

Now, let’s have a look at those scripts. The first one is to do the backup, in my case I’m doing a backup of the subversion, mysql and files under /var/www.

The script starts with the following block:

echo `date '+%F %T'`: Starting the backup

#Dumping the repos
echo `date '+%F %T'`: Starting the dump of the repos
for i in /user/local/svn/*/; do
    repo=`basename $i`
    echo `date '+%F %T'`: Dumping repo $repo
    /usr/bin/svnadmin dump /usr/local/svn/$repo > /backups/data/svn/$repo.dump
    echo `date '+%F %T'`: Repo $repo dumped
done

We suppose that the svn folder is located at /usr/local/svn, basically here we are going through each folder inside /usr/local/svn/ and we call svnadmin dump to dump that repository in one file, that file is stored in /backups/data/svn/.

#Dumping the DB
echo `date '+%F %T'`: Starting the dump of the DataBases
for i in /var/lib/mysql/*/; do
    db=`basename $i`
    echo `date '+%F %T'`: Dumping DB $db
    /usr/bin/mysqldump -uroot -p$db_password $db > /backups/data/db/$db.sql
    echo `date '+%F %T'`: Database $db dumped
done

In this second block we are doing more or less the same thing, we are going through each folder on /var/lib/mysql/ and calling mysqldump to export each DB in one file stored at /backups/data/db/.

#Copy all the websites
echo `date '+%F %T'`: Starting the dump of websites
for i in /var/www/*/; do
    site=`basename $i`
    echo `date '+%F %T'`: Dumping site $site
    /usr/bin/7z a -mx6 -t7z /backups/data/www/$site.7z -p$compression_password /var/www/$site
    echo `date '+%F %T'`: Site $site dumped
done

In the third block we are dumping the websites, I have the websites stored at /var/www folder and each site is inside a folder with the domain as folder name. Basically we are doing the same, loop through /var/www/ and compressing each site individually in a .7z file with a compression level of 6 and secured with a password.
I store each site in a separate file because if I have to restore a site I don’t need to uncompress all the sites, just the main file and then the compressed site.
I was playing with different compression levels and 6 is the most suitable to maintain a good compression ratio without wasting a lot of time.

#Compressing all the data
echo `date '+%F %T'`: Compressing the info
filename=$(date +%Y%m%d)
/usr/bin/7z a -mx6 -t7z /backups/compressed/$filename.7z -p$password /backups/data/*
echo `date '+%F %T'`: Info compressed

Now with all the information we want to backup in place we will compress all together in one single file, that’s the purpose of this block of code, the final filename is a timestamp of today using the date command.

#Upload to Amazon S3
echo `date '+%F %T'`: Uploading to Amazon S3
/usr/bin/s3cmd put --no-progress /backups/compressed/$filename.7z s3://BUCKET_NAME/$filename.7z
echo `date '+%F %T'`: Upload completed

Ok, we have the compressed file and one of the final steps is upload this file to Amazon S3. For that task we are using the s3cmd tool passing the parameter –no-progress to avoid an “interactive” output of the upload status.

#Delete the local backups
echo `date '+%F %T'`: Cleaning up
rm -Rf /backups/data/svn/*
rm -Rf /backups/data/db/*
rm -Rf /backups/data/www/*
rm -Rf /backups/compressed/*
echo `date '+%F %T'`: Clean completed
echo `date '+%F %T'`: Backup completed

And the final block of code is just a clean up, after the upload to amazon we delete all the files we have generated inside the /backups folder.

Ok, seems complex but is pretty strightforward, also if you take a look you’ll see that all the messages contains a timestamp, with that information we are able to determine how many time we spend in each task.
One disadvantage of this script is that we are not checking if the file was uploaded correctly to Amazon, maybe this will be a future improvement.

Maintenance script

Now let’s take a look at the other script, the purpose is just delete old backups based on a timestamp, in my case we’re storing the backups for one month, it’s very affordable with the Amazon prices.

for filename in `s3cmd ls s3://$bucket`; do
    if [[ $filename =~ ([0-9]*)\.7z ]]; then
        timestamp=${BASH_REMATCH[1]}
        echo `date '+%F %T'` - Reading metadata of: $filename
        echo -e "\tFilename: $filename"
        echo -e "\tTimestamp: $timestamp"
        if [[ $timestamp -le $limit ]]; then
            let "total=total+1"
            echo -e "\tResult: Backup deleted\n"
            /usr/bin/s3cmd del $filename
        else
            echo -e "\tResult: Backup keeped\n"
        fi
    fi
done

This is the only code block we have in the maintenance script, the idea is to retrieve the list of files we have in the bucket with s3cmd, then we check if the gived part contains the pattern ([0-9]*)\.7z (because the command s3cmd ls gives more information rather than just the filenames).
If we detect a segment that matches the regex we get the filename without the extension (the timestamp of the backup), and we check in this case if the timestamp is older than one month (the timestamp of one month ago is stored in the $limit variable). If the backup is older we remove it calling the s3cmd del command.

If you need to store the files more time just change the $limit variable and that’s it.

Wow, seems a large process, ok, now let’s have a look at the last step to let this work, the cronjobs.
I created to cronjobs and redirected the output of them to the stdout because I want to receive an email after the backup, my crontab look like this:

# m h  dom mon dow   command
MAILTO=YOUR_EMAIL_ADDRESS_HERE
00 22 * * * /backups/scripts/s3backup 2>&1
00 23 * * * /backups/scripts/s3backup-maintenance 2>&1

Just put there the values you want to run the crons and don’t forget to put at the end 2>&1.

Conclusion

With this system you’ll have your backups in a safe and cheap place without headaches and with a full report in you email every time the script runs. For sure these scripts can be impoved with a few checks and you can extend it to fit your needs.
I hope you have enjoyed this HowTo and begin to use this scripts! For sure improvements are welcomed, don’t hesitate to comment!.

Source code

Grab the full source code of the backup script and the maintenance script.

Hemos creado una herramienta, que en su versión beta funciona por terminal, que nos va a ayudar en este proceso, básicamente las funciones que realiza son:

1. Descarga e instala la última versión de CodeIgniter desde la página oficial.
2. Aplica el parche de idioma en castellano a CodeIgniter.
3. Descargar e instala la última versión del editor WYSISYG TinyMCE desde la página oficial.
4. Instala también la versión comprimida del editor TinyMCE.
5. Descarga la última versión de Prototype desde la página oficial.
6. Descarga la última versión de Script.aculo.us desde la página oficial.
7. Crea el fichero robots.txt con el contenido por defecto para los bots de búsquedas.
8. Crea la carpeta css.
9. Crea la carpeta img.
10. Crea la carpeta js.
11. Crea la carpeta swf.
12. Crea el fichero .htaccess con las directivas necesarias para que funcione CodeIgniter con mod_rewrite y permite el acceso a todas las carpetas creadas.

Las características que esperamos tener en la versión estable a parte de las existentes son:

1. Selección del idioma a instalar con CodeIgniter.
2. TinyMCE, Prototype y Script.aculo.us pasarán a ser instalaciónes opcionales (podremos escogerlo en el momento de la instalación).
3. En caso de instalar TinyMCE podremos escoger el idioma que queremos instalar así como la versión, estándar o comprimida.
4. Posibilidad de nombrar a las carpetas de imágenes, css, js y swf de la manera que nosotros queramos (se decide en el momento de la instalación).
5. Integración en el propio sistema operativo (Solo para Linux y MacOS de momento), es decir desde el terminal escribiremos installci y automáticamente se ejecutará el script.
6. Integración con el Finder de MacOS.

Para ejecutar el script hay que crear una carpeta dónde vamos a ir metiendo nuestros ficheros, copiar ahí el script installci.sh otorgar permisos con chmod 777 ./installci.sh y ejecutar dicho script con ./installci.sh.

De momento y hasta que esté disponible la versión estable aquí os dejamos el enlace para descargar la versión beta. Esperamos vuestras sugerencias y opiniones en los comentarios.