Plesk panel, backup strategy when low in space

Plesk backup is a real pain in the backside, if your server disk space is limited, even when choosing to backup in a ftp repository. All the files are created locally and then send over via ftp.

Prerequisites

Note that in order to implement this backup strategy, one must have an external backup space available like rsync.net (which I use) so that you can use the “rsync” command to transfer your files.

Minimising disk usage

In order to exclude any gigantic compressed (or not) archives being stored in your local hard drive, here is a little guide to help you avoid filling your server disk.

The first thing to backup regularly is the Plesk server configuration, this backup will not save the websites/email/database data but the content/configuration of your Panel, which is the first thing to restore if your server packs up.

Backing up Plesk (11) configuration

  1. Open your Plesk Panel as Admin
  2. Choose Tools & Settings from the Server Management sub-menu
  3. Click on Backup Manager
  4. Select Scheduled Backup Settings
  5. Activate the scheduled backup
  6. Select Store backup in: Server repository (or you can chose ftp there also as the files aren’t big, a couple of MB’s)
  7. I have set the Maximum number of backups in repository to “3″, but you can choose another value here
  8. Under the Backup content section, select  “
  9. Press OK

Obviously the choice of Schedule and prefix is at your convenience, I personally back up every day at 00:10 and the prefix is set to “configuration”.

If you aren’t using ftp, the content of this backup is stored in the /var/lib/psa/dumps/ directory. So in order to backup this on another server, simple rsync this location with a command that could be:

rsync -avz /var/lib/psa/dumps/ user@domain.rsync.net:var/lib/psa/dumps

If you don’t want to keep aggregated data add the –delete option:

rsync -avz --delete /var/lib/psa/dumps/ user@domain.rsync.net:var/lib/psa/dumps

To automate

To automate all this simply stick it in a cron (one can use the “Scheduled Tasks” under “Tools & Settings” (select root user) with a command that could look like this:

nice -20 rsync -avz --stats --delete /var/lib/psa/dumps/ user@domain.rsync.net:var/lib/psa/dumps 2>&1 | mail -s "backups dir rsync report" you@youremail

Databases

I will refer to MySQL databases in this section.

Database content is important, and you must back them up regularly, be it incrementally or not. I have Perl scripts that are in charge of dumping the content of the entire dataset and compress it. The file for my setup ends up being about 300MB, which is acceptable. I proceed to dump the content of the dataset via a “schedule” (root cron) and another cron simply “rsync’s” this file over to the backup server.

Email

All the email accounts are in /var/qmail/mailnames, the process is the same as above, use a rsync via a cron:

rsync -avz /var/lib/qmail/mainames/ user@domain.rsync.net:var/qmail/mailnames

Website content

Same as email but the directory is /var/www/vhosts/ so:

rsync -avz /var/www/vhosts/ user@domain.rsync.net:var/www/vhosts

There you have it, obviously I am providing this entirely as guidance and will in no way be liable for any loss you may get using these instructions. Even if you are on a cloud server (like me) it is a good idea to be able to extract files, especially databases or web content should a mistake be made that a cloud server cannot prevent like deleting a site by mistake etc…

Feel free to comment if you have any questions or if I have missed some important bits to backups that a Plesk backup may make which aren’t in this article.

Backup strategy – off site backups

The various elements of the backup strategy having been defined and documented earlier, the last step involves the off site backup of the local backups.

This is done using the rsync command to mirror the entire content of the local backups directory as all backups are stored under this directory.

In case of disaster the off site backup could either be burned on a series of DVD’s and posted to the DC to have them restored or sent back to the dedicated server via ftp or other, this is where it is important to have a good backup server capable of coping well with large files.

If I were to rsync all the backup content on my own internal network backup server, this would be quite fast to pull, however ADSL push would need a serious amount of time to upload the content back, even though it is probably the safest way to keep data. And having over 500GB of available space it makes sense.

So I might very well do that as a disaster recovery option…

Have yet to decide. It’ll probably a combination of local network and other remote backup site…

Backup strategy – Websites

Each individual websites are now backed up within Plesk’s schedule once a week and stored on the local backups/dumps/* directory ( Note that this path has been linked from the default Plesk path to increase disk space)

All the sites have a rolling backup where 2 backups are kept, except for a few very large website generating several GigaBytes backups.

Backup strategy – Databases

The mysql database is backed up on a seven days rolling dump. these files are stored under the local backups/mysql directory.

In addition, the classifieds database is backed up weekly and stored for ever… Just in case we’re facing problem with past advertisers, legal challenges etc…

These backups are performed via a Plesk root scheduled cron and the Perl script invoked handles the database sanitation and backup on the fly. The Perl script is stored within the sharpnet private area so it’s self contained and will work out of the box in case of a restore…

Backup strategy – Appliance

The First stage of the backup strategy is to have a full clean backup of the web server content, including emails.

This creates a rather large file (around 16GB), that take about 10 hours to be created, therefore you don’t want to do this every day. This file will be kept in addition of the monthly backups

The current plan is to have these dumped in the local /backups/full directory once a month and then rsync it to the backup server (I haven’t yet decided which one).

These backups are performed via a Plesk root scheduled cron and the Perl script invoked handles the database sanitation and backup on the fly. The Perl script is stored within the sharpnet private area so it’s self contained and will work out of the box in case of a restore…

Backups – the strategy

Hello me.

As the new Sharpnet strategy is being put in place. I will do the harduous task of documenting all the steps involved in the new backup strategy adopted to protect our asset (the server data).

After a few brainstorm followed by a few restful nights, I have arrived to the following strategy:-

  • Remove all unnecessary content from the websites hosted on the server
  • Backup the appliance (using pleskbackup)
  • FTP the content of every website monthly
  • Rsync the httpdocs of every website daily
  • Rsync the content of the most important databases, daily, on a sever days rolling backup
  • Backup the most important databases weekly and keep them for as long as possible.

This is the plan.

Watch this space…

Website Migration

Most websites were transfered from he US server to the UK server by August 18. Only emails needing SPAM filtering and all the highest trafficked websites remain on the US server, Urchin Stats are also managed by the US server, the only glitch has been the transfer of a Invision Powerboard over to the new server which does not support this configuration (it is a optional extra I do not need as they are on the US server as standard…)

The other problem today is that mydomain.com messed up the DNS pointers for all co.uk domains!

this is not good at all!!

Server Migration – Update

Progress is being made into the transition from the USA server to the UK server for the Websites. The Urchin stats log files had to be moved to a ftp readable directory as the current “statistics” folder did not allow ftp access. Daily Synchronisation of the US server backups are also made to the UK server using cron. In addition, mysql databases are also successfully transfered from one server to the other without loss of info by rsyncing /usr/var/mysql/* (bar some precious folders and files). This is very promising.

I expect the websites to be moving to the new server within a fortnight… Once all the websites are transfered. the backup will be made in the opposite direction to maintain integrity. An announcement will be made later on this week to advise website owners not to change their website’s content.

Some more tests need to be made for feedback forms sending emails to the local machine as it might be a potential problem once the UK server is serving/scripting pages.

Server Migration – Update

Currently no progress has been made towards streamlining the dedicated servers operation. Test have been made and all is likely to work on the UK server, however limitations in the software licensing does not allow Spam filtering on the UK server. Also Urchin Stats are only allowed on the US server, given for free by the Data Center Support.

So the plan is currently to host the websites on the UK server as this is primordial for speedy delivery on mainly UK/EU customers and Email service will be on the USA server.

Mirroring of the Websites will be made onto the US server in case of problem on the UK server. Allowing me to switch DNS within hours if necessary…

As for email. A full US server backup will be made and copied both locally and remotely (UK) to prevent loss of email data.

In addition a full UK server backup will also be made weekly on a backup server allocated with the UK server which is in a 3rd location, making the whole system totally redundant and (hopefully) free from data loss risk due to act of gods of any kind.

Having email and websites separated has also got the benefit of reducing the load of the server by half on both machines, this is also going to make website content delivery much quicker…

I believe that it is the best option available at the present time.