Jordan,

Thanks for the pointer. I'll try it out today.

What I'm trying to do is figure out how to get a 10TB file system back in the shortest amount of time. ndmpcopy and rsync both took over 4 days to complete and are not really acceptable. Since I know I can do a baseline Snapvault or Snapmirror of the same file system in less than 12 hours, I'm trying to figure out how to recover in a similar amount of time.

Thanks,

Jeff

On Wed, Sep 18, 2013 at 5:58 PM, Jordan Slingerland < Jordan.Slingerland@independenthealth.com> wrote:

I may be confused about exactly what you re trying to accomplish...but if not, see if the the bit on "Making the SnapVault Destination Writable" in TR-3446 helps you. You may (not sure) also be able to do this with a flexclone of the volume too if you are licensed.

--JMS

http://www.netapp.com/us/media/tr-3446.pdf&chrome=true

10.5 Making the SnapVault Destination Writable

Perform the following steps to convert an Open Systems SnapVault or SnapVault secondary backup

destination to a usable/writable destination (typically for DR situations). All the commands are done on

the SnapVault secondary (destination) system.

1. Secondary: Turn SnapMirror and SnapVault off.

2. Secondary: Switch to privileged mode (priv set diag).

3. Secondary: Convert SnapVault qtree to SnapMirror qtree (snapmirror

convert

<sec_qtree_path>).

4. Secondary: Turn SnapMirror on.

5. Secondary: Quiesce the qtree.

6. Secondary: Break the mirror, making it writable.

7. Secondary: Turn SnapVault on

---

*From:* toasters-bounces@teaparty.net [toasters-bounces@teaparty.net] on behalf of Jeff Cleverley [jeff.cleverley@avagotech.com] *Sent:* Wednesday, September 18, 2013 6:41 PM *To:* Toasters@teaparty.net *Subject:* Recovery options using SM

Greetings,

I'm experimenting with DR recovery options on filers running 8.1.2P4, 7-mode. We have 10G connections on all the filers. I wanted to use SM since we get close to 1TB/hr transfer between primary and secondary for SM/SV relationships and we have licenses for this on everything. I can't figure how to get data from the SV secondary back to the primary volume using SM.

It won't let me set up a SM on the secondary volume because it is a replication destination. I can't delete the baseline snapshot, and a snapvault stop can take 6 hours or more. Once it completes, the destination qtree is gone and SM won't work.

I'm going to look into SnapRestore, but it will require some new licenses for some of the filers. Ndmpcopy seems unstable for 10TB volume transfers and is extremely slow and takes days. Rsync of a volume with 50m files takes days also, partly because the rsync system only has a 1G connection.

Thanks,

Jeff

-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611

Jordan,

Thanks for the pointer. I have a snapmirror going. I'll see how long it takes.

Jeff

On Thu, Sep 19, 2013 at 9:13 AM, Jordan Slingerland < Jordan.Slingerland@independenthealth.com> wrote:

After these steps, you should see that if you do qtree status on the volume/qtree , the status should change from Snapvaulted to normal.****

---

---

--JMS****

---

---

*From:* Jeff Cleverley [mailto:jeff.cleverley@avagotech.com] *Sent:* Thursday, September 19, 2013 11:07 AM *To:* Jordan Slingerland *Cc:* Toasters@teaparty.net *Subject:* Re: Recovery options using SM****

---

Jordan,

Thanks for the pointer. I'll try it out today.****

What I'm trying to do is figure out how to get a 10TB file system back in the shortest amount of time. ndmpcopy and rsync both took over 4 days to complete and are not really acceptable. Since I know I can do a baseline Snapvault or Snapmirror of the same file system in less than 12 hours, I'm trying to figure out how to recover in a similar amount of time.****

Thanks,****

Jeff****

---

On Wed, Sep 18, 2013 at 5:58 PM, Jordan Slingerland < Jordan.Slingerland@independenthealth.com> wrote:****

I may be confused about exactly what you re trying to accomplish...but if not, see if the the bit on "Making the SnapVault Destination Writable" in TR-3446 helps you. You may (not sure) also be able to do this with a flexclone of the volume too if you are licensed.

--JMS

http://www.netapp.com/us/media/tr-3446.pdf&chrome=true

10.5 Making the SnapVault Destination Writable

Perform the following steps to convert an Open Systems SnapVault or SnapVault secondary backup

destination to a usable/writable destination (typically for DR situations). All the commands are done on

the SnapVault secondary (destination) system.

1. Secondary: Turn SnapMirror and SnapVault off.

2. Secondary: Switch to privileged mode (priv set diag).

3. Secondary: Convert SnapVault qtree to SnapMirror qtree (snapmirror

convert

<sec_qtree_path>).

4. Secondary: Turn SnapMirror on.

5. Secondary: Quiesce the qtree.

6. Secondary: Break the mirror, making it writable.

7. Secondary: Turn SnapVault on

---

---

*From:* toasters-bounces@teaparty.net [toasters-bounces@teaparty.net] on behalf of Jeff Cleverley [jeff.cleverley@avagotech.com] *Sent:* Wednesday, September 18, 2013 6:41 PM *To:* Toasters@teaparty.net *Subject:* Recovery options using SM****

Greetings,****

I'm experimenting with DR recovery options on filers running 8.1.2P4, 7-mode. We have 10G connections on all the filers. I wanted to use SM since we get close to 1TB/hr transfer between primary and secondary for SM/SV relationships and we have licenses for this on everything. I can't figure how to get data from the SV secondary back to the primary volume using SM.****

It won't let me set up a SM on the secondary volume because it is a replication destination. I can't delete the baseline snapshot, and a snapvault stop can take 6 hours or more. Once it completes, the destination qtree is gone and SM won't work.****

---

I'm going to look into SnapRestore, but it will require some new licenses for some of the filers. Ndmpcopy seems unstable for 10TB volume transfers and is extremely slow and takes days. Rsync of a volume with 50m files takes days also, partly because the rsync system only has a 1G connection.

---

Thanks,

Jeff****

---

-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611****

-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611****

Judging by the log files, it was probably a couple of minutes. The quiesce and break commands ran pretty quick also.

Jeff

On Thu, Sep 19, 2013 at 4:50 PM, Jordan Slingerland < Jordan.Slingerland@independenthealth.com> wrote:

how long did the snapmirror convert take? I meant to warn you that it may be a bit, but not crazy long.

an hour?

--JMS

---

*From:* Jeff Cleverley [jeff.cleverley@avagotech.com] *Sent:* Thursday, September 19, 2013 5:33 PM

*To:* Jordan Slingerland *Cc:* Toasters@teaparty.net *Subject:* Re: Recovery options using SM

Jordan,

Thanks for the pointer. I have a snapmirror going. I'll see how long it takes.

Jeff

On Thu, Sep 19, 2013 at 9:13 AM, Jordan Slingerland < Jordan.Slingerland@independenthealth.com> wrote:

...

After these steps, you should see that if you do qtree status on the volume/qtree , the status should change from Snapvaulted to normal.****

---

---

--JMS****

---

---

*From:* Jeff Cleverley [mailto:jeff.cleverley@avagotech.com] *Sent:* Thursday, September 19, 2013 11:07 AM *To:* Jordan Slingerland *Cc:* Toasters@teaparty.net *Subject:* Re: Recovery options using SM****

---

Jordan,

Thanks for the pointer. I'll try it out today.****

What I'm trying to do is figure out how to get a 10TB file system back in the shortest amount of time. ndmpcopy and rsync both took over 4 days to complete and are not really acceptable. Since I know I can do a baseline Snapvault or Snapmirror of the same file system in less than 12 hours, I'm trying to figure out how to recover in a similar amount of time.****

Thanks,****

Jeff****

---

On Wed, Sep 18, 2013 at 5:58 PM, Jordan Slingerland < Jordan.Slingerland@independenthealth.com> wrote:****

I may be confused about exactly what you re trying to accomplish...but if not, see if the the bit on "Making the SnapVault Destination Writable" in TR-3446 helps you. You may (not sure) also be able to do this with a flexclone of the volume too if you are licensed.

--JMS

http://www.netapp.com/us/media/tr-3446.pdf&chrome=true

10.5 Making the SnapVault Destination Writable

Perform the following steps to convert an Open Systems SnapVault or SnapVault secondary backup

destination to a usable/writable destination (typically for DR situations). All the commands are done on

the SnapVault secondary (destination) system.

1. Secondary: Turn SnapMirror and SnapVault off.

2. Secondary: Switch to privileged mode (priv set diag).

3. Secondary: Convert SnapVault qtree to SnapMirror qtree (snapmirror

convert

<sec_qtree_path>).

4. Secondary: Turn SnapMirror on.

5. Secondary: Quiesce the qtree.

6. Secondary: Break the mirror, making it writable.

7. Secondary: Turn SnapVault on

---

---

*From:* toasters-bounces@teaparty.net [toasters-bounces@teaparty.net] on behalf of Jeff Cleverley [jeff.cleverley@avagotech.com] *Sent:* Wednesday, September 18, 2013 6:41 PM *To:* Toasters@teaparty.net *Subject:* Recovery options using SM****

Greetings,****

I'm experimenting with DR recovery options on filers running 8.1.2P4, 7-mode. We have 10G connections on all the filers. I wanted to use SM since we get close to 1TB/hr transfer between primary and secondary for SM/SV relationships and we have licenses for this on everything. I can't figure how to get data from the SV secondary back to the primary volume using SM.****

It won't let me set up a SM on the secondary volume because it is a replication destination. I can't delete the baseline snapshot, and a snapvault stop can take 6 hours or more. Once it completes, the destination qtree is gone and SM won't work.****

---

I'm going to look into SnapRestore, but it will require some new licenses for some of the filers. Ndmpcopy seems unstable for 10TB volume transfers and is extremely slow and takes days. Rsync of a volume with 50m files takes days also, partly because the rsync system only has a 1G connection.

---

Thanks,

Jeff****

---

-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611****

-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611****

-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611