Linux penguin logo in front of the dropbox logo

In this guide I will explain how to create a backup solution for your Linux server using a basic shell script and Dropbox. It’s good for text files but not so good for bigger media files such as audio and video.

It works as follows:

  • We install Dropbox on our server
  • Then we create a shell script that will copy all the directories you want to backup to a temp directory
  • An finally we compress that temp directory into our Dropbox folder and remove the temp files

I use this method to backup all my Git repositories, MySQL databases, project source code and my server configuration files. A free Dropbox account gives you 2GB of storage, which should be enough for some compressed text files as well as a couple of databases.

Now for the how to.

First, sign register with Dropbox. Then follow the instructions at the following link to install it on your Linux box.

If you already started the Dropbox daemon in the above guide, press ctrl+c to kill this process. Now we are going to start it again but this time as a background process:

($HOME/.dropbox-dist/dropboxd &)&

Now create a new directory in your Dropbox to store the backups. You should change ‘server_name’ to a name relevant to your server.

mkdir -p ~/Dropbox/backups/server_name

Next we will start to create our backup script. In this tutorial I use vi however you should use whichever text editor you prefer.

vi ~/Dropbox/backups/server_name/

Modify and add the below content accordingly. I have added comments above each line to confirm what it does:


#Variable with current date and time (for the file name)
DATE_NAME=$(date +'%Y-%m-%d-%H-%M-%S')

#Your dropbox backup location.
#Modify ‘username’ and ‘server_name’ accordingly

#The temp location to copy all files
#The full url for the temp directory 
#including the date/time directory

#The full temp URLS for each directory you want to backup

#Create the directories above

#Perform the backups, this is where you go to town
#by copying all the files you want to backup
cp -R "/usr/local/repo/" "$TEMP_GIT_BACKUP_DIR_URL"
cp -R "/usr/local/sites/" "$TEMP_SITES_BACKUP_DIR_URL"
cp -R "/etc/nginx/sites-available/" "$TEMP_NGINX_CONFIG_DIR_URL"
cp /etc/nginx/*.common $TEMP_NGINX_CONFIG_DIR_URL
cp -R "/etc/supervisor/conf.d/" "$TEMP_SUPERVISOR_CONFIG_DIR_URL"

#This will backup all my databases
#Modify ‘backup_username’ and ‘PASSWORD’ accordingly
mysqldump -u backup_username -pPASSWORD --all-databases > "$TEMP_MYSQL_DATABASE_BACKUP_DIR_URL/databases.sql"

#Now we change into the temp directory
#We tar up and compress the files to backup
#and output the tar into our Dropbox

#Now we can delete the temp backup directory

Now we modify crontab. Make sure you are switched to the same user that you install Dropbox on, and edit your crontab file by typing the following command:

crontab -e

Next we are going to add two lines to the crontab file. The first line will ensure that Dropbox re-starts automatically if you reboot your server. The second will execute our backups daily at 7PM and output the backup log to your home directory.

@reboot ~/.dropbox-dist/dropboxd
0 19 * * * cd ~/Dropbox/backups/server_name/ && sh > ~/backup.log

There is a great guide on crontab here if you are looking to learn more or change the times to schedule your backups.

Now we are done and your server backups will be automatically synchronized to your Dropbox. I do not recommend this for production environments where you may need to restore backups quickly, but you could use it for your personal or non-critical systems.

4 replies
  1. Mike
    Mike says:

    I used to use this exact technique for backing up servers – but if your server was hacked, not only would your server data be compromised, but the backups in the dropbox you made would also be compromised too, not to mention any files you happened to put in the dropbox – which I eventually started doing.
    In order to minimise potential data sabotage/loses, I used a dedicated dropbox account.
    I also copied new backup snapshots, like your command


    does, but then when you take a look in the server after 6, 12, 18months, you will have hundreds of these tarballs.
    Nowadays, I NEVER give a server any kind of access or credentials of any kind into “sensitive” locations, I only ever pull data FROM a server TO a safe/clean location – where the credentials access to the sensitive accounts reside in a safe location.
    Also, by using rsync instead of tarballing you can limit to to only one backup. I know it can potentially be handy to have a history of backups in case you need to go back to and old old version , but this could be achieved with some conditional checks in your script, but in my experience I never really needed to go back to some old backup. In fact I have actually never needed to restore a server from a backup like this , but I still would do it just in case.
    Nice article though, thanks

    • mark
      mark says:

      Thank you for taking the time to leave such a detailed comment. Yes I completely agree and I would not recommend using this method in a live production environment however, it is interesting to see what you can do with a simple script and a free Dropbox account though 🙂

  2. Patrick Carter
    Patrick Carter says:

    I entered my name and email address but was never given any opportunity to download you PDF step by step guide. Would you be kind enough to forward it on?

    • mark
      mark says:

      Hi Patrick, sorry about that. Which post were you trying to download a PDF for? As this one doesn’t have a PDF option.

Comments are closed.