Many companies replicate data between sites. The specific methodology may be different; different vendors, different solutions, etc., but the end goal is basically the same….data redundancy to ensure as smooth a transition as possible should a DR event occur.
To look at one specific replication scenario, a number of my clients use Veeam to backup their virtual machines to backup repositories located on DataDomain appliances and then that data is replicated to a DataDomain appliance located at another site. Now I know, assuming I have green checks indicating my data is in sync in DD Enterprise Manager, that the data is replicated and if need be, usable in the secondary site. But still, it’s a good idea to test the data thus ensuring its integrity.
Looking at DataDomain articles, seems the first step in testing the replicated data is to break the replication context with the source system so that you can convert the replicated data from read-only to read-write. But I really don’t want to have to break replication connections in order to test the integrity of my data, so I called DD support who suggested I use fastcopy to make a read-write copy of the replicated data for DR/data integrity testing.
I asked, “What happens if I don’t have enough room to make a copy?” and was told that fastcopy uses “pointers”, “will not consume any additional space” and “the easiest method for r/w access for a DR test would be to fastcopy the replicated data.” Sounds too good to be true but I decided to test it as follows:
1. Created a new VM, a new backup repository on the DD, and then replicated the new DD MTree from the source to the destination DD. (Wasn’t going to try it out the first time with my production data)
2. After replication was successful, I created a new, blank MTree on the destination DD system. **If you do not create a blank MTree, the fastcopy command will fail as it is unable to create MTree’s on its own.
3. Execute the fastcopy command, an example of which is shown below:
- filesys fastcopy source /data/col1/CAN-DR-Test destination /data/col1/VMTest
- NOTE: The command is case sensitive, remember that when specifying your source and destination MTree
4. In DD Enterprise Manager, enable CIFS share for the replicated MTree (VMTest in this example)
5. Add VMTest as a backup repository in Veeam, importing existing backups, and then perform a restore.
In this instance, the process worked perfectly and thus ensured the client that their data was indeed replicating and accessible if needed.