Home / server / Questions / 184124
In Process
abenci
Asked: 2010-09-24 13:17:51 +0800 CST

Backup on a remote server

  • 772

We have just solved the problem of stolen server by hiding an external backup unit in a different room of our office.

Now the problem is fire and all the other possilble disaster that can happen. We used to do an FTP upload of a password portected archive to an oversea server but the size of the backup is increased too much (bare metal recovery ~22GB) and it is not possible anymore. Most of the data is inside a MS SQL Server database (800MB).

What are the options we have to protect our data even in this case?

We don't have an high speed connection to any datacenter here and we are looking for a fully automated solution.

Thanks.

backup data-recovery

4 Answers

  1. How much of your database changes on a daily basis? We backup MS-SQL databases on 35 sites overnight via ADSL using BackupPC, which uses rsync to copy only the file differences. The way we do the backups is as follows:

    1) At 9pm, a scheduled script on the Windows server dumps a copy of the database to a backup file. Databases range in size from about 4GB to 11GB

    2) The database backup is split into 250MB sections using a free tool call Swiss File Knife.

    3) BackupPC copies all the 250MB files to the backup server.

    The splitting of the file into smaller part files allows BackupPC to totally skip copying the parts that have not changed since the last backup, and on the backup server itself only one copy of each identical part file has to be kept in the backup sets, although BackupPC makes each daily backup look complete by using hard links between each one to represent the files that have not changed overnight.

    On sites with few daily changes, the backup takes around 30 minutes. On sites with slow ADSL lines (288K upload only) and a lot of changes, it takes about 4 hours, but it is totally automatic.

    • 1

  2. Get a fireproof safe and put it in your office. Place the USB HDD/tapes in this safe.

    Also, consider taking backup media offsite as well. Fireproof safe at the bosses house too?

    • 0

  3. Perhaps this could be useful:

    Three external HDDs labeled Safe1, Safe2 and Safe3. Two external HDDs labeled Bank1 and Bank2.

    At the end of each week, perform a full backup to one of the HDDs, and then, put it in a fireproof safe, located on site.

    On the first week of the month, perform the backup on one of the disks labeled Bank and deposit it in a safe offsite location.

    Use the media in a rotational pattern, swapping the disk at the bank every month and keeping a track of what data is stored where (what disk contains the most recent backup data).

    Two disks in rotation are enough for onsite storage, but using three makes things simple - separate drive for three weeks between backups for bank deposit.

    We use something very similar to this setup.

    Hope it helps. Luke

    • 0

  4. You didn't say whether it was the size of the upload that caused a problem with the FTP Upload you used to do, or the expected time to download it again in case of a Disaster Recovery situation?

    If it's just the upload time, then you could significantly reduce this by using incremental SQL backups (which compress very well) after an initial full backup.

    • 0