A backup strategy is NOT a technical decision, it is the
result of applying technical expertise to business decisions regarding RPO
(Recovery Point Objective) and RTO (Recovery Time Objective).
For example, if you are backing up a 5T database, it doesn’t
really matter if you are backing up frequently if you can’t restore within your
own defined SLA (Service Level Agreement). On top of that, you must (and
usually will) need to decided what amount of data is a reasonable loss (if
any). That is to say, if you are backing up your database daily, and taking
incremental backups hourly, can you afford to lose the 30-minutes worth of data
that will be lost, on average, should the servers crash.
In addition, you need to discuss the types of disaster you
are backing up for. For example, if you don’t have an air-gapped backup, you
may be paying ransomware at some point in your future.
For a very small (few hundred gig) system, you might
backup:
Full backups every 24 hours,
Log Backups every 15 minutes,
And realize that you have decided that a 7.5-minute loss is
something that you live with if everything hits the fan.
If you have a multi-terabyte database, you may find that it
takes hours to backup the “standard” way and that you need to use other tools,
hardware, or perhaps add differential backups to the mix.
And in either case, make very sure that you have:
- Made sure that the
backup is free of corruption
- Instructed the
system group to sweep the backups off the target disks
- Tested your restore
process from the remote storage.
Backups are a 4-hour lecture; or a 30-minute
white board session with executives. This is only a start.
