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.