BURR...backup, recovery, and restore

[outofthewoods]

I wanted to introduce a new acronym, BURR (backup, recovery, and restore). It goes without saying data is backed up, because at some point it may need to be recovered. What people may not realize, you can recover a corrupt file..which is useless.

Why you actually backup data is to be able to recover it and then restore it, so it can be useable.

What are you delivering to achieve this in your SLA

[Samantha Morris]

Bump.

I know we have quite a few Managed Service Providers around here. Is anyone doing anything unique (beyond software) when it comes to backup and recovery?
Is there an industry standard is for SLAs and how do you exceed those expectations to creative a competitive advantage?

[gaulfinger]

We look for backup solutions that have several key features:

1. Use APIs that trigger application checks (DB integrity checks, for example) during the backup to warn if there's something already wrong with the data source
2. Has automated scans of data on disk to make sure values don't change (disk or RAID controller) error.
3. Use storage solutions that have data scrubbing capabilities (ie. disk arrays, not tape)
4. Application awareness that can look at a backup and recognize it as an Exchange server, SQL database, etc. and validate that the data structures are good.

Gary

[aravindhaltruist]

1.Using API s to check consistency of the source data will take longer time as we backup huge data and issue raises with backup windows.
2.Also most of the software prodcuts has add on modules to recongize wtherther data is from exchnage or SQL.

[Samantha Morris]

Aravidhaltruist -- How would you define "huge" data? And how do you ensure the consistency of the source data without the use of APIs?

[aravindhaltruist]

My intention is to consider all scenarios.

backup window is important in BURR.
Data can be considered as huge when the backup runs out of the time window and checking source data consistency everytime before starting the backup might need some extra time but helpfull if it checks for any expected errors before starting the backup.

Just as an info every backup tool has an option to verify the backedup data but this is after backup is done.

[gaulfinger]

Well yes, that is a general sense of 'huge.' But if you're doing backups and an old DAT tape that moves 4MBps, then a 100GB database might seem huge. If you're running on 10gE to disk, then 10TB might be okay for an eight hour window. So APIs slowing the backup is only meaningful if you're underling architecture isn't adequate to the task.

As a practice, validating backups is a good idea to make sure the system isn't generating TB's of junk.