Hi,
I think the following happened.
Snapshots locked by snapvault are registered in the root volume and in the volumes itself. Therefore since the new controllers used new root volumes the systems were unaware of any snapshot used as a base for snapvault relationships. This would also have been apparent by the lack of snapshots with "snapvault" behind it in the "snap list" output.
After swapping root volumes there is still not a problem. If you execute "snapvault updates" for all the relationships, either scheduled from the secondary or manual, ONTAP would have discovered the base snapshots again (no resync required) and registered them as a snapvault base snapshot in the new root volumes.
I now assume that the base snapshots got deleted by the snapvault schedules set on the primary or another process before the snapvault updates were executed.
The following KB describes something similar: https://kb.netapp.com/support/index?page=content&id=2012214
-- Pascal Dukers ASML IT Datacenter/Network General Phone +31(0)402684341
-----Original Message----- From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Jeff Cleverley Sent: Friday, July 05, 2013 11:23 PM To: Filip Sneppe Cc: Toasters@teaparty.net Subject: Re: Snapvault snapshots lost after upgrade.
Filip,
We don't use any level of DFM to manage the snapshots, so the baseline name doesn't contain any of that. That doesn't mean it isn't embedded in the meta data somewhere.
The hosts were renamed to the same hosts they were before so that part is OK. I tried both the snapvault start -S and snapvault start -r and neither works. I also tried specifying the the acs snapshot using the "-s" option on a snapvault update. Everything fails saying the base snapshot is no longer there.
I've moved aggregates from one partner to another and was able to modify the snapvault relationship to reflect the new source location and that worked. That should have had the original filer ID/serial number in it if that was the case.
For right now I'm not getting very far with NetApp since they are running a skeleton crew this week. We have another business group that is purchasing updated heads. I've had to tell them not to do the upgrade until we figure out what the problem is.
Apparently the only solution right now is to re-baseline 400+ TB. I'm not sure I even have that much available so we'll end up having to delete a bunch of snapshots and possibly some destination volumes.
Thanks,
Jeff
On Fri, Jul 5, 2013 at 12:09 AM, Filip Sneppe filip.sneppe@gmail.com wrote:
Possibly because the system is confused because of the new system id/serial which is part of the snapshot name. You did use exactly the same system names ? They are case sensitive as far as snapshot naming is concerned. Or Protection Manager may have deleted them because it is confused about something. Can you restart them with "snapvault start -S -r" ?
On Fri, Jul 5, 2013 at 3:08 AM, Jeff Cleverley jeff.cleverley@avagotech.com wrote:
Greetings,
I upgraded heads on our filers. The new 6290s had their own disks and
I
have 8.1.2P4 on them. The old 6080s were 7.3.5.1P4. For the update I
kept
the 6290 root/vol0 drives and changed ownership of all the other
drives.
The aggregates were brought online and all the volumes came up OK.
I'm now
seeing none of my backups are running because the snapvault
snapshot is
missing. I still have the acs snapshot. I've tried the snapvault start -S command and it says it is already a snapvault relationship. When I try
to
tell it to do a snapvault update, it says the base snapshot no longer
exists
on the source.
What happened to all my snapvault snapshots? Why did the snapvault snapshots get released? I thought those were in the volume and
should have
carried over in the hardware migration. I still have access to the old
root
volumes and backups of the old root volumes if there is anything that
can be
salvaged. I would rather not have to re-baseline 100+TB of source
data.
Thanks,
Jeff
-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611