Rotating the Mirror vs. Rotating the Data Repository

When you would like to store your data offsite, you can choose to Mirror your Data Repository or you can replace your Data Repository to store the old media off-site. Review the following pros and cons to decide which works best in your situation.

*** Lockstep recommends rotating the Mirror drive rather than the primary Data Repository drive. ***

Benefits of Rotating the Mirror

Why would I decide to rotate my Mirror? When you would like to frequently take data off-site, we recommend that you follow the rotating Mirror plan. Rotating the Mirror allows you to leave your Data Repository "as is" and simply move a copy of the Data Repository (the Mirror) to an off-site location for safekeeping.  Leaving the Data Repository in place ensures its normal operation and availability to users.  All of the backup history is retained on both the Data Repository and the Mirror.

Problems with Rotating the Mirror

If data stored on the Data Repository for some reason becomes corrupted, the corrupted data is replicated to the Mirror, effectively placing corrupted data in both places.

Why would I decide to rotate my Data Repository? - Some users choose this option when they think in terms of Archiving. They decide to rotate the Data Repository because they are thinking, "We have an Archiving policy to comply with. I need to take all of our data off-site every quarter. It is the end of the quarter and now I would like to take everything off-site and start fresh with new media." Rotating the Data Repository on this infrequent basis allows you to comply with your Archiving policies.

If you find that you need to rotate data off-site frequently (daily or weekly), consider using the Mirror for this purpose. We recommend using the Mirror in a rotation schedule because it is not disruptive to your Backup Clients.

Benefits of Rotating the Data Repository

Each Data Repository has an independent copy of the backup data. In other words, if something affects one copy of the Data Repository, the other copies in the rotation pool are not affected.
Backup Clients can store more revisions of a file because their revisions are tied to the Data Repository. For example, let's say you wanted to maintain 60-days worth of revisions. If you use 1 Data Repository for 60 days and then rotate it to a new Data Repository that you use for 60 days, your Backup Clients now have effectively 120 days worth of file revision history.

Problems with Rotating the Data Repository

The first instance of rotation invokes a complete re-baseline backup to occur, which is time consuming. Each time the Data Repository is rotated, the Backup Clients need to resynchronize with the new Data Repository. This resynchronization process takes a little time when the first backup occurs after the Data Repository is changed.

When using multiple Data Repositories in a rotation schedule, you may need to cycle through one or more of the Data Repositories should you need to restore a very specific version of a file. For example, if you need to restore a very old version of a file by a specific date that you have in mind, you will need to be running the Data Repository that was in use at that time. Using our example above in which you have 2 Data Repositories, in which you use each for 60 days apiece, if you want to restore a file as it existed in the first 60-day rotation cycle (or a file that is 61 to 120 days old) you will need to restore from the first Data Repository.