As promised, Here is the next part of my series on backing up a remote Linux server.
This script is still quite straight forward but on the up side, the more straight forward it is, the easier it is to troubleshoot if something goes wrong down the line.
It does a few things. It downloads all the archives in the backup directory, checks that their downloaded and if the check is successful it runs a check to make sure there are no problems. If something has gone wrong, it is logged to a file matching that date with an extention of .err.
scp YourRemoteUserName@IPAddressOfServer:backups/*.gz /home/YourUserName/backups/$thisdate/ && echo $thisdate files downloaded from server into $backupdir >> $logdir/$thisdate.log && backupstatus=success
if [ $backupstatus=”success” ]; then
ls $backupdir/$thisdate/ && echo $thisdate files are in $backupdir/$thisdate >> $logdir/$thisdate.log
tar ztvf $backupdir/$thisdate/*.gz && echo $thisdate archive archive checked and decompress correctly. >> $logdir/$thisdate.log && backupstatus=success
ls $backupdir/$thisdate/ && backupstatus=failed1
if [ backupstatus = “failed1” ]; then
echo $thisdate The files did not download >> $logdir/$thisdate.err
tar ztvf $backupdir/$thisdate/*.gz 2> $logdir/$thisdate.err
As always, I like to clean up my variables. The declarations of these are at the top and the bottom of the script.
In the middle is where the interesting stuff is.
As in the last script, the command after the && will only run after the first command completes successfully. Therefore, it’s a great way of easily checking for the right exit status.
So, when I run ls on the directory that should hold that nights backups, I’m validating the check done above that the download was indeed successful.
The next check is much more important. It makes sure that the downloaded archives are readable. notice the t switch after the tar command. “tar -ztvf”. Again, if this is not successfull, the log won’t be updated and the variable continues to be set to success.
Of course, if things fail, I want to know why! So, that’s where the next if block comes in. Instead of just writing success or fail status messages to the logs, it puts something meaningful into the error log. By piping the errors from the tar command, we’ll see what has happened. Is the file there, or is the archive corrupt.
Of course, there’s one draw back to this. What happens if not all the archives are generated on the server side? Well, that’s where the logs on the server come in to play. It would be nice to have them all together in one place but that’s an easy enough job using a few other commands.
In the next part of this, I will look at backing up indevidual MySQL databases.