![]() ![]() When restoring a crash-consistent snapshot image of your entire system (as in common in a virtualized environment), normal InterSystems IRIS startup recovery automatically ensures both physical integrity (including completion of interrupted writes) through the write image journal or WIJ (see the “ Write Image Journaling” chapter of this guide), and logical integrity (including transaction rollback) through journaling. ![]() This means that any backup approach you use must include each database’s journal files. ![]() While the backup approaches described in this chapter can provide you with a physically consistent copy of databases that can be individually restored, you must also do a journal restore, even if you have no journals newer than the time of the backup, to ensure that any transactions that were open at the time of the backup are rolled back. Restore the transactional integrity of the database by rolling back uncommitted transactions. Restores all journaled updates from the time of the backup to the time of the failure. This journal restore accomplishes the following: In the event of a failure that requires restoring from backup, you must also apply journal files (described in the “ Journaling” chapter of this guide) to the restored copy of the database. Importance of Journal RestoreĪ restorable backup of an InterSystems IRIS® database alone is not enough to provide a viable restore of production data. To protect enterprise databases from a disaster that could destroy the data center, regularly ship backup media to a secure off-site location. (Depending on your needs, you may have less stringent performance requirements of the storage device used for restoring backups, allowing for a less expensive storage solution.) In this way, the last-known good backup is always available for use in a disaster even if validation of the current backup fails. Therefore, the server on which you are validating the backup should ideally have twice the storage space required by production-space to store the last-known good backup as well as the backup you are currently validating. Once you restore the backup and establish that it is a viable source of recovery, it is best to preserve that restored copy until you establish the next good backup. See the Importance of Journals section for more information. To perform these checks, you may need to restore journal files to restore transactional integrity. To further validate that the application is working correctly on the restored database, you can also perform application-level checks. If you discover an integrity error in the restored database, immediately run an integrity check on the production database to verify the integrity of the production system. The converse, however, is not true: an integrity error detected on the restored copy of a database does not necessarily imply that there are integrity problems on the production database there could, for example, be errors in the backup media. The backup strategies described in this document preserve the physical structure of the database therefore, a clean integrity check of the restored copy implies that the integrity of the production database was sound at the time of the backup. ![]() If such an event occurs, you need only restore the updates in the journal files. Provides a warm copy of the backup, substantially reducing the time required to restore the backup in the event of a disaster. Validates the physical integrity of the databases in the backup, avoiding the problem of false reporting of integrity errors when running integrity checks on volatile databases affected by ongoing updates. Validates the recoverability of the backup media. The best practice - to restore every backup of the production environment to an alternate server and then validate the integrity of the restored databases (see Verifying Structural Integrity in the “Introduction to Data Integrity” chapter of this guide) - provides the following advantages: Regardless of the backup strategies you use, it is critical to restore backups on a regular basis to validate your procedures. If you require more information to help you to develop a backup strategy tailored for your environment, or to review your current backup practices, contact the InterSystems Worldwide Response Center (WRC) Opens in a new tab. The chapter also contains details about the procedures used to perform these tasks using either native or third-party utilities.īackup strategies can differ depending upon your operating system, preferred backup utilities, disk configurations, and backup devices. It discusses techniques for ensuring the integrity and recoverability of your backups, as well as suggested backup strategies. This chapter outlines the factors to consider when developing a solid plan for backing up your system. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |