Hi guys. I had a funny issue a few days ago. We have the following:

• Volume with a single LUN in it both space guaranteed
• 2 snapshots in the volume
• 2 flexclones hanging off those snaps
• fractional reserve set to 0
• auto-grow disabled

Now, what happened was that the volume went to 100% but the LUN remained online. The OS saw that the disk had plenty of space on it and was trying to copy some large files onto it. The entire OS went into a hang because it couldn't commit the writes to the Storage. I would have assumed that the LUN would be brought offline in such a circumstances no?

What is snap vault?what is the difference between Snap mirror and snap vault?

I have snapcenter plug-in for VMware and the underlying protocol is FC for the storage connectivity. 

I want to retain more snapcenter snapshots at the secondary storage and hence planning to use “mirror-vault” policy for SM relation and update snapvault after back up option in plugin. 

To restore a VM from vault backup what is the connectivity requirement from secondary storage to snapcenter plugin/vcenter/host. Do I need any fc connectivity as primary is based on FC protocol ?

Hi,

I'm really new to netapp so forgive me that i don't know the commands and options from the system.

We have a older Netapp (FAS940, ontap version 7.0.5) which should be totally wiped before we get rid of it.

The netapp has 2 disk shelf's, then 2 heads and another 3 disk shelf's. (heads both see their own disks and the others as partner disks)

I managed to get the above 2 disk shelfs wiped (with some help) by moving the root volume to a newly created aggegate.

There was a arregate with 3 disks so we just rebuild that one, moved the root volume to it and sanitized the other 25 disks.

Now, the other one has only 1 arregate with 42 disks divided into 3 raid groups.

There is only 1 spare disk available. The root volume is also on this arregate.

How can i possible wsanitize these disks?

I want to have the same setup as the other head, so 3 disks for the root volume and all other disks for the data. (meaning sanitized and set to spare)

But i cant find a way to get 2 disks of the other arregate, or any other way to get 2 additional spare disks to create a new arregate for a root volume.

How can i get this?

Thanks in advance for your help!

(netapp is no longer in use / production. It contains no data and should be prepared for selling. That's why I need to have all disks sanitized so data recovery will be impossible. I just need a working netapp like it came from the factory)

Hi! Usually the Linux command mount does not list  .snapshot/* directories but on one of our virtual machines it does, for a single volume only. On other virtual machines it doesn't for this and any other volume.

Have you any idea what could cause this?

Configuration:

• FAS2750
• VM OS Debian 10 (Buster)
• VM kernel 4.19.269-1
• NFS package nfs-common 1:1.3.4-2.5+deb10u1
• NFS v3

Kind regards,

Harri

Hi all,

I was wondering about size needed for Snapshot volume R/W operation, as per my experience SS volume doesnt use snapshot reserved space for these

operation - so I will need to plan extra space on volume group, in case I need to use snapshot volume for data recovery.

Any idea what is the optimum size for minimum write operation?
Why SS volume is not utilizing snapshot reserved space?
Will coping from that SS volume require write space as well, even so data was copied to another volume?

Hi all,

what should I do to make NAS volume writable again if it is completely full with data and Snapshot copies? I guess, I should delete Snapshot copies and remove data from active file system? Is it enough? Is there anything what should be done with mirror relationships?

I have a few issues with Snapshot/SnapMirror I would like to address with a Product Mgr.

1. De-swizzle or its replacement is taking an extra-ordinary amount of time, during which time no SnapMirror updates can take place.  This is a definite GAP in SM as a DR/Backup solution - talking week or more
2. If a volume is out of space the SM/SV snapshot is rotated in the destination, but not created in the source;  this causes the replication to become irreparably broken; another GAP.
3. SVM-DR is likewise affected by above, except that in first example, NO volumes are updated until that single volume finishes;  I've had a 92TB volume take 14 days to do post processing, during which time my SVM-DR for all volumes was stopped.

I'd like to discuss issuing an RFE request, if that is still possible.

So the other day I was performing initial steps to decommission a NetApp cluster. We are keeping it in place for two weeks so we can restore from snapshots if needed. As part of the decommission, I of course removed SnapMirror and SnapCenter jobs. Much to my shock, removing the SnapCenter job in the vCenter plug-in (i.e. the Resource Group) removed not only the job but ALL THE SNAPSHOTS that the job had created!! It felt like I'd been hit with a virus.

Needless to say I opened a case. My second shock was to discover this is BY DESIGN:

https://docs.netapp.com/us-en/sc-plugin-vmware-vsphere/scpivs44_manage_resource_groups.html#delete-resource-groups

To me this is amazing that this is default behavior, with no way to change it as far as I can tell. I am requesting a feature request to allow a check box to override this behavior, but wanted to post it here for additional visibility. I can't imagine anyone thinking that deleting a backup job would delete the backups. I've never seen a single backup software program do that in my life, from any vendor.

Anyone from NetApp care to comment? Can this be changed?

Hello All,

We have got 15 new NetApp Arrays under our managed services. We want to start billing for NAS so as to bring the loading revenue.  How to go about this.  What are the steps and models available.  Please suggest.

Thank You.

I have a question about the configuration of snapcenter plugin for vmware vsphere; If I configure the policy options 'Update snapvault after backup' and the 'snapmirror label' Am I still required to configure the snapshot policy and snapmirror policy via Ontap?

Hi to all

The customer has a old filer, with snapvault destination volumes and aggrs inside that.They bought a new controller with new disks.We will ,first configure the new filer for future snapvault destinatinon.Then they want us to connect the old filers shelves to the new controller.

My question is about the snapvault volumes, they have been in place for the last 5 years, and lots of data inside them.

If we connect the old shelves to new filer, and assign the disks to this new filer, do we have the old structure of aggrs and volumes with snapshots?.Or do we loose snapshots or something else,

In my opinion, all the aggr, volume and snapshots must retain ,but i havent tried something like that.

what is your opinion?

regards

Hi, 

is it possible to "dump" snapshot from ONTAP Select to Wasabi (or from FAS/AFF)?

Tnx.

Running NetApp Release 9.6P3 and VMWare ESXi 6.5.  I have 3 separate datastores on the NetApp that are presented to the 4 ESXi hosts and all is well.  I'm trying to test the process of mounting one of the volume snapshots that NetApp takes throughout the day and mount it as a new LUN in vSphere so I can interact with the virtual machines on that restored LUN.  Using the following method, I can get the snapshot mounted and active within the ONTAP System Manager, but in refreshing and scanning new storage on the vSphere side, it never shows up so I'm missing something.  In ONTAP, I goto Storage\Volumes and select my Volume.  More Actions\Clone\Create\Volume and I give the volume a new name and select an existing Snapshot.  After that I goto Storage\LUNs and edit the new volume and enable the only Initiator Group listed which is the same as the production LUNs.  After that, I'm not sure what to do as I can never see it in vSphere.  Where am I going wrong?

From SMB2.0 it is only possible to access the ~snapshot folder from an ONTAP junction point. In SMB1 the ~snapshot tree could be entered at any folder. This is described here:

https://library.netapp.com/ecmdocs/ECMP1196891/html/GUID-6D832809-1E60-4041-BF08-D390CB6B3D89.html 

I have found that if I take a UNC, append \~snapshot to it and map that to a drive letter it works but has anyone got a more elegant solution? Is there a freeware tool that will give access to the ~snapshot tree at an arbitrary  place in the hierarchy? 

I don't want to subvert security.

Thank you

Hi,

It's been a while since this first happened. But now it's annoying. In our environment from Windows 2008R2/Windows 7 we can do \\filer\share\.snahshot. From Windows 2012 R2\Windows 8\10 i cannot access that path. Just says Windows cannot access that path.

We are running OnTap 8.2.4P3. With SMB 2 enabled.

Appreciate any help

I have some questions which I might know the answer as I used to work for NetApp but need confirmation, please reply to me only.

Snapshot policies can only be created on Cluster or VMS (VSERVER) level right?

Snapshot policies when created in vserver level, does not mean all volumes will inherit the policy within that vserver, that is only when we actually apply the policy to the volume, right?

If I create a snapshot policy on a cluster level it does not mean all volumes will also inherit the policy within the cluster, right?

I can delete/edit the root volume of the cluster and also of the vserver VOLUME-ROOT?

Is there a way to apply the cluster snap policy to all volumes? Is there a way to apply the vserver snap policy to all volumes?

Is the Vserver root volume default policy always be there even when we apply another policy to the vserver itself?

We are performing volume-level data restores from one cluster/SVM to another cluster/SVM and currently it's a manually process. In the latest AIQUM, I see that we can perform such data restores thru AIQUM UI (Restoring data using the Health/Volume details page). So it would be nice to have this feature via API as well.

Hi,

We are working with NAS Snapshots on FAS2552, OnTap 8.3.2 .

Once the Volume snapshots are taken the Snapshots are NFS mounted on a host from where the contents are copied to a secondary storage. At this point we are observing that the inode number of files are changing in different snapshots. For e.g., a file F1 under snapshot 1 is different than the one under snapshot 2. Interestingly this file is not touched at all between the snapshots.

More so, this behavior is observed only when the snapshot is mounted on NFS v3.

See the below outputs -

----- NFS Version 3  --------

10.xx.xx.147:/demo_nas_vol1 on /ver3_mnt type nfs (rw,relatime,vers=3,rsize=65536,wsize=65536,....addr=10.xx.xx.147)

[root@nfshost ~]# stat -c %i /ver3_mnt/.snapshot/snap1_for_inodeTest/fileone.txt
858188230
[root@nfshost ~]# stat -c %i /ver3_mnt/.snapshot/snap2_for_inodeTest/fileone.txt
858188486

----  NFS Version 4  -----
10.xx.xx.147:/demo_nas_vol1 on /ver4_mnt type nfs4 (rw,relatime,vers=4.0,rsize=65536,wsize=65536,....addr=10.xx.xx.147)

[root@nfshost ~]# stat -c %i /ver4_mnt/.snapshot/snap1_for_inodeTest/fileone.txt
13510
[root@nfshost ~]# stat -c %i /ver4_mnt/.snapshot/snap2_for_inodeTest/fileone.txt
13510

So my question is - 

1. Is this expected behavior

2. What can be done to have consistent behavior

Hi All,

Was hoping I could get some help with this. I have a customer who needs to keep data in snapshots, on a snapvault destination, for greater than 1 year, and in some cases multiple years.

Now in 7-mode this was easy, you would schedule a snapshot to be taken of the destination volume whenever you wanted, and script it that way. NOW, in CDOT, you aren't able to take snapshots of a snapvault destination volume independent of the snapvault process.

I'm currently exploring the idea of snapshotting the source side, and sending a snapshot along via snapvault, but it's getting VERY complicated. My thought is , with such a big push to CDOT, there must be a fix or a solution that someone can think of for those customers that don't want to push their backups to tape, and have upwards of 7 year retentions. If such a solution exists already that someone can think of I would be incredibly grateful.

Any help would be MUCH MUCH appreciated!

Thanks very much!!!

Matt

We have been using "volume move" to shuffle volumes around our cluster, being told that it is a great tool, and will cut-over cleanly.

Well, I've found out that it isn't so clean.  When "volume move start" is executed, it appears to create a snapshot for the copy.  It then proceeds copying data from that snapshot, and including snapshots which existed prior to the "volume move start" snapshot.  Once it is ready to trigger the cutover, it updates, I believe, from the origination snapshot, cuts-over the volume, but does not update files created or modified after the origination snapshot.

This has been wreaking havoc with our moves, with users telling us their data has reverted to a prior time;  I now believe the users are correct.

-Unfortunately, I could not find any documentation or TR's which address the issue.  So I must assume it is an issue with the volume move command.

-One caveat, is we did not have snapmirror licensed on the entire cluster.  Perhaps that would cause "volume move" not to be able to update, however, there should have been a note in the documentation.

If anyone at NetApp can address this, that would be great.  I'd like to know if "volume move" can be used in future, or if I need to go back to good old Volume SnapMirror.

We have in the past had issues with our existing snapshots which are at a volume level (CSV data) on our filers - in that the data has been corrupted previously and was inconsistent.

What is the recommended process for snapshots of CSV data where our VMs are stored?

Should we be using SnapDrive for Hyper-V instead, if so what disadvantages would this have? i.e. if the SnapDrive service stops for any reason will the snapshots stop, etc.

Our source filers are running 8.3.2P2 (yes I know they need to be upgraded, it is arranged for a time in the future) with our destination filers running 9.1P14.

If anyone could off any advise that would be great.

Thanks,