Backup and Recovery Plan Design
It is recommended that you develop and implement a backup schedule to protect your data. You should also ensure that you have created and tested your backup and recovery commands as part of your backup and recovery plan.
- Where are the database files located?
- What files need to be backed up?
- Where are the backup files stored?
- How does the backup affect performance of your database or application?
- Will the database server be running while you run the backup?
- Failed media
- Failed hardware
- File corruption
The cluster database maintains configuration information for all nodes in the cluster. It also holds policy configuration, data services, and cluster cache data. When you add, remove, or change one or more of these things, back up the database if you don't have an alternative backup plan (for example, exporting the services file).
Typically, a backup uses a combination of full and incremental backups. The frequency of each backup type depends on the type of data that you are protecting. You should also validate your backups to ensure that they can be used for recovery.
You can use the scheduling features to automate the task of backing up your database. Once you specify a schedule, the backups are performed automatically by the database server.
The length of time your organization can function without access to the data in your database determines the maximum recovery time.
You should verify that you have the protection you need against media failure on the database file and on the transaction log file. If you are running in a replication environment, you should consider using a transaction log mirror.
External factors such as available hardware, the size of database files, recovery medium, disk space, and unexpected errors can affect your recovery time. When planning a backup strategy, you should allow additional recovery time for tasks such as entering recovery commands or retrieving and loading tapes.