Unsolved
This post is more than 5 years old
1 Rookie
•
20.4K Posts
0
2150
Snapvx and cascaded snap restore
I am going over this document https://www.emc.com/collateral/technical-documentation/h13697-emc-vmax3-local-replication.pdf , specifically how to deal with cascaded snapshot restores.
So let's say i have a reporting database that is a "nocopy" linked snapshot of my production DB, it gets relinked everyday to a new snapshot to provide reporting application with fresh data. Say DBAs want to make changes to reporting DB but want to be able to quickly recover it in case their change goes really bad. If i am reading the document correctly (bottom of page 14). It says that "A cascaded snapshot can only restore to a linked target that is in copy mode and has fully copied." So that means that before i can even attempt the restore, i have to change my linked target snapshot to "copy", wait for it to finish the fully copy which could take a long time and only then i can restore from my cascaded snapshot ? I am reading/understanding this correctly ?
If that is the case i just doubled my SRP utilization because i had to copy my entire source data to my linked (now "copy") snapshot. How would i get back to my original configuration ? Would i have to "free" every single target device and re-create my "nocopy" linked snapshot again ? Any thoughts/comments ?
Thank you
Ayrton_Senna1
62 Posts
0
March 13th, 2017 16:00
Looks like we definitely needs to convert the target to full copy mode before you can restore which ofcourse doubles the consumption in SRP.
Coming to your question,Assuming you are done with the restore and want to go back to original setup.
how about un-linking the full copy snapshot and relink in nocopy mode instead of freeing the extents? I haven't tested it though but would like to give it a shot if this would be a quicker way to get back the space on those targets.
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
0
March 14th, 2017 09:00
Did you read Appendix D in the document i linked to earlier ?
Ayrton_Senna1
62 Posts
0
March 14th, 2017 10:00
Did read it now. So, unlinking a defined copy will not give us back much space in SRP as it retains the deltas and shared tracks. So, the only way to get back space is by performing "free all" on target devices.
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
0
March 14th, 2017 11:00
that's how i am interpreting that paragraphs. This is crazy, i want to terminate my snapshots and all delta to go away automatically just like it used to with symsnap. I don't have time to wait for devices to be freed before i can re-link another set of snapshots.
Raghavan_HSBC
9 Posts
0
March 14th, 2017 22:00
the scenario that you described doesn't match with cascaded snapshot scenario that is depicted.
cascaded snapshot refers to snapshot that is taken on Target volume (that your DBA indirectly referring to Prod DB) givent to Test server.
in your scenario - each new snaphsot taken on ProdDB volumes, and you link/unlink to Test server; should anythong go wrong and you want to roll back - all just you need is to shut/un-mount on Test server and relink to the last snapshot that you linked with.
Also Relink is not same as Restore. In Relink - either you can point to differen point-in time, or to revert all the changes made on Target by simply relink to the last snpshot.
In Restore - you actually restoring from Target to Prod.
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
0
March 15th, 2017 07:00
please re-read my question, I need to protect my Reporting DB.
LBM99
119 Posts
1
March 24th, 2017 06:00
Hi all,
As of the code from Q1 2016, a nocopy linked target with a cascaded snapshot can be unlinked. So you could do that and then restore from the snapshot.
As for needing to freeing the target manually after unlink, this was a deliberate change because being able to access the nocopy data after unlink provides additional flexibility.
If you will be using the same set of target devs/same SG, there is no need to free them. The subsequent link will deallocate data as needed. This is discussed in an FAQ doc that was recently published:
http://www.emc.com/collateral/faq/timefinder-snapvx-faqs.pdf