|
With a SAN, creating several differential-copy snapshots throughout the day provides multiple recovery points. Instead of recovering the production database from tape and rolling 10 hours of logs forward, you may be able to recover the database from a 45-minute-old snapshot and roll the logs forward from that point. This assumes a logical corruption, not a physical loss of data. This example is not as straightforward as the NAS
example. Here are several points to consider.
- How easy is it to create a consistent image of the application's data? For a useful snapshot, the data must be in a consistent state when a snapshot is created.
- Does the application have a "hot backup" mode? Most database apps have this mode to ensure data files and associated logs are in a state that allows them to be backed up cleanly. If the app lacks such a mode, it should be shut down for the data in the snapshot to be useful.
- What impact does the hot backup mode have on application performance? If the hot backup mode has a significant negative effect on performance, then a synchronous full-copy snapshot may be a better choice.
- How long will it take to create the snapshot? If it takes 30 minutes to create the snapshot, it doesn't make sense to do a snapshot every hour. Ideally, snapshots should take only seconds.
- Are third-party software tools needed to create a consistent image? Sometimes third-party tools provide a better interface for coordinating snapshot creation. If a packaged product meets a company's needs, the ease of management typically outweighs the utility's cost.
- Will the data files need to be checked before they can be used in production? In many cases, this check can be done immediately after the snapshot is created. Consistency checks typically generate considerable I/O and CPU load. Ideally, the check is done by another host that connects to the snapshot.
- For large applications, will multiple snapshots need to be created at the same time and across several different storage devices? Large apps typically have several storage locations spread across SAN, NAS or locally attached disks. An analysis is required to determine how "synchronous" the snapshot creation associated with all of the storage locations needs to be. For example, document management systems typically have a database on a SAN or DAS disk that stores the locations of documents. The documents may be stored on a NAS server. It's important that every document reference in the database snapshot have a corresponding document in the NAS snapshot. Otherwise, if the system is restored to a previous state using a snapshot, it will be necessary to verify that documents referenced in the database exist on the NAS device.
|
 |
|
