This page maps out some philosophical best practices for backup.
Company policy should state the service level requirements for data restoration. These policies will generally result in statements on RPO Recovery_point_objective and RTO Recovery_time_objective levels which may vary by data category. These objectives will drive the decisions on what products to use and how they are used to achieve
As much as possible, backups should be automated. Automate the initiation of backup jobs. Automate any replication jobs. Automate the shipping of the backups off-site. If possible, automate adds, changes, and deletions of workload backups based on it's metadata. Any human intervention in these steps can and will probably result in a failure to adhere to policy standards at some point.
Hybrid approaches to backup and restore can meet multiple goals. On-site, fast storage for speed of backup and restore, and off-site, slower-to-reach storage which is automatically updated via network. Lots of buzz-words surround this type of setup disk-to-disk-to-cloud, for example (D2D2C). What's important is the multiple layers to meet different goals.
Virtualization simplifies backup by leveraging operating system Quiesceing tools to take snapshots at the virtual bare-metal level. These snapshots can be used to eliminate the need for backup windows, as the underlying workload can continue to operate after the quiesced snapshot is created. In addition, virtualization environments provide a hardware abstraction layer, enabling workloads to be much more easily restored to dissimilar hardware. This means disaster recovery and bare-metal restores (Bare-metal_restore) are much easier to plan for and implement.
Physical or virtual workloads need to have a bare-metal restore image available. Any hypervisor-aware backup tool will leverage APIs, VSS, and snapshots to get quiesced bare-metal images. For physical workloads there are several tools that can be used.