Storage at the DR site does not need to be same as the original site. The DR site may use cheaper storage, and operate at somewhat lower performance.
8. Use Snapshot-Based Backup
As the amount of data for backup increases, it becomes more costly. In order to minimize disruption to production servers, backups are executed during the night independently and without supervision. This may result in failures, or alternatively, organizations pay extra for a night shift to be present during the process. Due to increasing production requirements and increasing data capacities, backup windows are in many cases not large enough to complete the required task. This leads to huge infrastructure upgrade expenses (e.g., servers, LAN, faster tapes, etc).
By using low-capacity snapshots for backups, there is no disturbance to production servers or the LAN. A dedicated backup server can be mounted to a snapshot and perform the backup at any given time. It eliminates the need to upgrade the servers or the LAN, and cancels the need to dedicate a night shift to supervise the backups.
9. Use of a Disaster Recovery Site for Backups
When a disaster recovery site exists, it can be used for backups. In this case, there is no need for a backup server, since the DR site already has servers on call for failure and can be used for other tasks. Backup tapes are frequently shipped to a remote vault, in which case, the DR site may function as the remote vault and the shipment costs are eliminated.
10. Use of a Disaster Recovery Site for Application Development and Testing
Disaster recovery sites typically have a very current mirror of the data, a large amount of equipment (e.g., servers, terminals, networks, printers, desks, etc.) and people that are just “waiting” for a disaster to occur. Development and testing teams may use this equipment for development and testing in order to save the cost of purchasing the same equipment for the main site.