Note:This topic was updated for 9.3.1.
Numerous occurrences could lead to data loss: data or database elements could be accidentally deleted; data could become corrupted by the addition of bad data; hardware, such as a disk or server, could fail; or disasters, such as flooding, could destroy your server and storage media.
Since much time, effort, and money are usually invested in an organization's data, it is unlikely that the loss of it would be a trivial thing. For this reason, it is critical that you have a tested recovery plan in place for your geodatabase. Notice the plan should be tested before it is implemented—you can back up all the data you want, but if you can't recover it, it is useless.
Backup and recovery strategy needs vary in accordance with your specific situation. For ArcSDE geodatabases for SQL Server Express, only simple backup and recovery are performed. A simple backup is a full backup. Since ArcSDE geodatabases for SQL Server Express are comparatively small and accessed by fewer users than ArcSDE geodatabases on the other supported database management systems (DBMS), it doesn't take as long to create full backup files, and they can be done more frequently. To learn more about this type of recovery model, see Simple backup and recovery.
For ArcSDE geodatabases on DB2, Informix, Oracle, PostgreSQL, or SQL Server, the type of backups you use, where the backups should be stored, when the backups should be performed, and when and how restoration can be done can be affected by the following interrelated factors:
How often the data changes
The more frequently the geodatabase and its contents are edited, the more frequently backups should be performed.
How important the data is to the organization
Is the data mission critical? If so, recovery time and currency of the recovered data are important. Is retention of the data of legal importance? If so, you should consider storing backups off-site.
How much time is acceptable for recovery
Certain data might be needed right away, whereas the need for other data isn't as pressing. If there isn't much data in the database, compare how much time it would take to perform a database recovery versus manually reentering data.
How much downtime can be tolerated
This affects whether or not you can take the database offline to perform backups or recover the data. If the data must be available 24 hours a day, be sure to schedule backups to occur during off-peak hours.
How big the database is
This affects storage space and location as well as the amount of time it takes to back up and recover the database.
What the system resources are with which you have to work
Is there ample storage space—both virtual and physical—for backups? Could you possibly set up a mirror or copy of your database? Is the network able to handle a backup or restore procedure taking place while users are still connected to the database? Would it make sense to have off-site consultants provide your database backup, storage, and recovery management?
The type of DBMS you're using
Each type of DBMS has different options for backup and recovery. For the basic concepts behind these options, see the types of backups listed below.Most DBMSs have their own administrative utility to perform backup and recovery management, but there are also many third-party software products available.
To see information on creating backups and restoring databases for each DBMS, consult the following topics:
