Making periodic backups is a common task. Synbak can help to simplify it.
Synbak brings together several different backup methods and provides a powerful reports system that provides details about all the work it does. Synbak can use rsync over Secure Shell (SSH), Server Message Block (SMB), or Common Internet File System (CIFS) and either create tar archives or burn CDs and DVDs (quaintly called laserdiscs in a throwback to old times). It can also access and back up MySQL and Oracle databases and Lightweight Directory Access Protocol (LDAP) servers. Finally, it can send you an email message with the backup details and create an HTML plus RSS Web page with the same information.
Synbak is available under the GNU GPL version 2 or later. The current version, 1.0.11, has been available for about a year. According to the author, version 1.0.12 is almost ready and should be published soon.
Synbak is available in the openSUSE repositories, but it produced an error message about missing files when I installed and ran it. Since Synbak actually consists of a lot of shell scripts, you're better off downloading the source packages from the official download site and then doing the following as root:
tar zxf synbak-1.0.11.tar.gz
This installs all the scripts quickly. You'll need some extra packages in order to use all possible commands, such as rsync or ssh for connection to remote systems and mkisofs and cdrecord to burn CDs. You must also be able to send email by using the mail command. Unfortunately, there is no detailed list of all the necessary packages, and you might discover yet another requirement; pay close attention when you do your first test runs to see if something pops up.
Pay special attention to the FAQ file in the download directory, because it's just about the only piece of documentation you'll get, apart from some comments in the example.conf file.
Defining backup jobs
Usually the root user will do the backups in order to be able to produce output, access devices, send mail, and so on; I'll assume that you'll work this way. Synbak stores all configurations in a hidden .synbak directory in your home directory. When you run your first Synbak command, it creates everything it needs and reminds you about creating the configuration file. For example, if you run synbak -s firstJob -m rsync to define a firstJob backup that uses rsync, you'll get:
synbak -s rsyncText -m rsync
ERROR: '/root/.synbak/rsync' directory doesn't exist or it isn't accessible
i just created it for you.
If this is a new backup task, copy the /root/.synbak/example.conf config file to the /root/.synbak/rsync directory so you don't have to create it from scratch:
cp /root/.synbak/example.conf /root/.synbak/rsync/firstJob.conf
In the synbak command, the name of the job goes after the -s option, and the method goes after -m. The following table shows the possible methods:
|rsync||To access a remote machine using rsync|
|mysql||To back up a MySQL database|
|oracle||To back up an Oracle database|
|ldap||To back up an LDAP database|
|tape||To write a tape backup|
|laserdisc||To burn a CD or DVD|
|tar||To create an archive (tar) file|
The first four methods let you get data from a foreign source, while the last three let you store data away somewhere. You should fully specify what should be backed up by editing the conf file. The following table shows the parameters you'll want to specify:
|backup_source = a list of directories||The remote directories you want to back up|
|backup_destination = a directory in your box||The home directory for the retrieved data|
|backup_exclude = an optional list of directories||Remote directories you don't want to back up|
|backup_incremental = yes or no||Whether to do an incremental backup (only changed files) or a full one (every file). Personally, I prefer no, so I will be getting all files, but for large volumes of data, yes might be more appropriate.|
|backup_erase_after = a number||How many old backups will be kept before Synbak starts erasing the oldest ones|
|backup_no_make_destdir = yes or no||If Synbak should create the destination directory if it doesn't exist. This supposedly works only with rsync backups -- you have to create the directory yourself if you use another method -- but I couldn't get it to work in my tests.|
|backup_erase_always = yes or no||Whether Synbak should erase old backups (see above) even if an error occurs|
|backup_remote_uri = where to find the remote data||This should be method://yourUser:yourPassword@theRemoteHost/aPathInIt, and the method can be ssh, rsync, smb, cifs, mysql, oracle, or ldap. If you're doing a database backup, you should specify a user/password with access to the database.|
|report_remote_uri_down = yes or no||Whether it should create a report if the remote machine is down.|
|backup_device_changer = the backup device||The tape, CD, or DVD writer; for example, /dev/cdrom|
|backup_verify = yes or no||Whether to verify the written data; you should probably say yes here|
|backup_device_eject = yes or no||Whether to eject the backup media at the end of the writing process|
Providing the appropriate parameters is your responsibility. For example, you need specify the CD writer device if you want to burn a CD with the retrieved backup data. You should also specify the output options, which include:
|report_stdout = yes or no||Whether to print the report to the standard output. You should specify yes if you're running the report by hand, and no if you're doing it via a cron job. In the latter case, don't forget to set the other parameters below, or you won't get any information.|
|report_stdout_on_errors = yes or no||Whether it should produce an output report on errors only|
|report_email = yes or no||Whether it should send an email message with the report; yes should be the value for an automatic backup job|
|report_email_on_errors = yes or no||Ditto, but for errors|
|report_email_rcpt = your email address||Who will get the Synbak emails|
|report_html = yes or no||Whether Synbak should produce a HTML report; "yes" is better|
|report_html_on_errors = yes or no||Whether Synbak should produce an HTML report on errors. I suggest yes here too.|
|report_html_destination = a path for your Web server||The root for all the Synbak generated files. It's probably something like /var/www/html/synbak for most distributions, or /srv/www/htdocs/synbak for openSUSE. I prefer having all created files in a Synbak directory, so they're be easier to delete at once.|
|report_html_uri = URL for the reports||The URL needed to access the reports. For the paths above, it should probably be http://localhost/synbak.|
|report_html_logo = yes or no||Whether a logo should be displayed in HTML reports|
|report_html_logo_image = path for the logo file||If the above option is yes, sets the path to the logo file|
|report_html_logo_link = URL to the logo file||The URL needed to access the logo file|
The (poor) documentation doesn't explain the default values, so to be safe and never omit any parameters.
Just for show, I prepared a simple configuration file to back up my laptop (at 192.168.0.200) documents and images to my desktop box.
backup_source = /home/fkereki/Images /home/fkereki/Documents backup_destination = /root/backup backup_exclude = backup_incremental = no backup_erase_after = 10 backup_no_make_destdir = yes backup_erase_always = no backup_method_opts = backup_remote_uri = ssh://email@example.com/ report_remote_uri_down = yes report_info_support = firstname.lastname@example.org report_stdout = yes report_stdout_on_errors = yes report_email= no report_email_on_errors = no report_email_rcpt = email@example.com report_html = yes report_html_on_errors = yes report_html_destination = /srv/www/htdocs/backups report_html_uri = http://127.0.0.1/backups report_html_logo= no report_html_logo_image = report_html_logo_link =
I then tried synbak -s laptopJob -m rsync a second time, and after a short while, I had copies of the remote /home/fkereki/Images and /home/fkereki/Documents directories in /root/backup -- nice! Check the screenshot for the HTML view; you'll see my previous failed attempts and the final successful backup.
Synbak is an interesting package with plenty of possibilities but insufficient documentation. However, if you take your time and are willing to experiment a little and try to decipher the available hints, you'll be able to use it to your satisfaction. I sent several queries to Synbak's author, Ugo Viti, and he was quite helpful, even providing me with an advance copy of version 1.0.12.