Blog

In light of my hosting issues over the last week, I decided it was time to take measures in ensuring all websites under my hosting provider are always backed up automatically. I generally take hosting backups offsite on an ad-hoc basis and entrust the hosting provider to keep up their end of the bargain by doing this on my behalf.

If you are with a hosting provider (like I was previously - A2 Hosting), who talks the talk but can't actually walk the walk in regards to the service they offer, you will more than likely end up having backup woes. It's always best practice to take control of your own backups and if this can be automated, makes life so much easier!

All Plesk panels have a "Backup Manager" area where you can action manual or scheduled backup processes. Depending on your hosting provider, the features shown in this area might be varied. Some have the option to backup straight to your Dropbox account. What we will be focusing on is remotely backing up our website data to our Synology NAS using FTP.

Before we log into Plesk to select our Remote Backup option, we need to carry out some setup on our Synology.

Port Forwarding for FTP and FTPS Protocols

Most likely, your router will have a limited number of ports open to allow outside internet traffic to enter the local network. To make the most of your Synology, there is a recommended number of ports you need to open to make use of all the services.

We are interested in opening to the following ports:

• FTP: 21
• FTPS: 990

I prefer to send over any data using FTPS just for better security.

You will have to login to your router settings to open ports. I would provide some instructions on how to do this, but every router is different. I just managed to find these settings hidden away in my own Billion router.

Synology Setup

Setting up FTP is pretty straight-forward. Just make sure you have administrative privileges to access the Control Panel.

Enable FTP

In Control Panel, go to: File services > FTP Tab.

All we need to do here is to enable two FTP settings:

• Enable FTP service (no encryption)
• Enable FTP SSL/TLS encryption (FTPS)

The reason why I selected the "Enable FTP service (no encryption)" option is purely for initial testing purposes. If there are any issues when making a connection via FTP from a new service for the first time, I just like to ensure if a successful connection can be made via standard FTP. After my testing is done, I would disable this option.

Create a Synology User

I prefer to create a new user specifically for FTP connections rather than my main own account, as I have the ability to lock down access to only read and write permissions in its home directory. No Synology services or applications will be accessible.

The only application I allow my user to access is "FTP".

Plesk Backup Manager Setup

FTP Configuration

In Backup Manager, go to "Remote Storage Settings and select "FTP". Enter the following settings along with your user credentials:

• FTP server hostname or IP: http://mysynology.synology.me
• Directory for backup files storage: /home
• Use passive mode:  Yes
• Use FTPS: Yes

On clicking the "OK" or "Apply" button should return no errors. But if there are errors, check the logs and ensure you haven't missed any permissions for your Synology user.

Set Backup Schedule

Now we have set our remote storage settings, we now need to put a schedule in place to generate a backup on as often as we require. It's up to on how often you set the regularity of the backups. I've set mine to run daily at 11pm and retain these backups for a month.

Make sure you set the Backup settings to store the backup in your newly created FTP storage.

A Word To The Wise

Just because we now have automatic backups running protecting us from any foreseen hosting issues, this doesn't mean we're all in the clear. Backups are useless to us if they don't work. I check my backups at least once a week and ensure the most recently backed up file is free from corruption and can be opened.

In light of what has happened recently with some 150,000 Google Account holders loosing their information due to a mishap at Google HQ over the weekend really reinforces the fact that our data is not safe…even in the “cloud”.

At the end of the day our information is stored on hardware that can fail. I think that this whole “cloud computing” malarkey has got all lured into a false sense of security where we think we don’t need to take measures to ensure our data backed up on a regular basis. I have to admit, I too have become a bit tardy when it comes to backing up my online data. If a large company like Google can get it wrong, what hope is there for other companies offering the same thing?

I practically live on the “cloud” in terms of what Google has to offer. I use their email, calendar, document and notebook applications. Even their mobile phone OS: Android! Luckily, there are steps we can take to ensure our data is backed up on your own terms:

	Google Calendar Google Calendar is the one application I use the most. If I lost all my data, I would quite annoyed to say the least (and be very disorganised). You can backup all your calendar entries by opening your calendar settings, click on Calendars and select “Export Calendars”. A zip file will be created containing your calendars in a .ical format.
	Gmail This a simple one. Use an desktop email client such as Thunderbird (or any other client you prefer) to download all your emails directly to you computer through POP access.
	Docs If you only store a handful of documents in your Google Account, you could just download them one-by-one. Understandably, if you have a long list of documents a more automated approach is required. Lifehacker.com shows a really great script you can use to that allows you to download documents in whatever format you require. Take a look here.

Hooray! Our data is saved!

In SharePoint 2003, you will notice when you change the name of a site, the change is not reflected in the intranet URL. Modifying the site name within “Site Settings” will only change the title that is displayed when you visit the site.

You have two options to change the site name you see in the URL:

1. Delete and recreate your site.
2. Backup your current site and restore content elsewhere on the intranet.

You really wouldn’t want to consider the first option if your SharePoint site currently stores high volume of information. The best option would be to carry out a backup and restore using SharePoint’s “stsadm” command prompt. The time it takes to run the backup and restore process will entirely depend on the size of your site.

So here’s the scenario. We have an intranet that currently contains a site called “InsuranceClaims”. However, this site needs to add additional data relating to employee health schemes. The site name in the web address needs to be renamed to “InsuranceAndHealthClaims”. In order to make this change, the following needs to be carried out:

1. Backup the “InsuranceClaims” site using the stsadm backup command. The site has been backed up to a file called insurancebackup.bak.

stsadm.exe -o backup -url http://intranet.computing-studio.com/sites/insuranceclaims -filename C:\insurancebackup.bak

2. Create a new site called “InsuranceAndHealthClaims” from the SharePoint intranet.
3. Restore the contents of the backup to the new site using the stsadm restore command.

stsadm.exe -o restore -url http://intranet.computing-studio.com/sites/insuranceandhealthclaims -filename C:\insurancebackup.bak

Providing all goes well when you run the backup and restore stsadm commands, you should get a “Operation completed successfully” message.