snapmirror file in snapshots

[gentle tulip]

hello team,

Been working with AWS FSx ONTAP for short while now. I have a question around the .snapshots directory.

Currently .snapshots folder holds daily.* , snapshot.* and snapmirror.* files. Of these files, what is the purpose of snapmirror.* file? Which process creates it and what schedule does it follow?

We have schedules and policy for snapshots and snapmirror but none of them generates any file with label "snapmirror". The file currently has a datetime stamp of 2024-03-27_020500 so I am guessing it gets generated at 2005 hrs but there is no schedule defined for that . Also current version of snapmirror.* file is consuming 77% of the primary storage space. how does this file relate to snapshots , if at all.

I am very confused by this file and have not been able to find much help on this.

Thanks in advance.

[whole swallow]

what you see there are not the snapshot labels, but the names of the snapshots. The "snapmirror" snapshots come from SnapMirror (async replication). It's also not a file but a directory that you can enter to see the filesystem from the point in time that particular snapshot was taken

if they show up as actual files then your CIFS client is broken (I have seen some similar issues with people using some linux file managers that don't understand CIFS reparse points and show them incorrectly, or something). But they are really directories

[gentle tulip]

thank you Darkstar for responding. If Snapmirror.* is a directory does its contents map with the snapshots contents in the DP volume? Can I see its contents via ONTAP CLI?

[whole swallow]

you can see it on your CIFS client (windows explorer) if it has CIFS shares in it. It's basically a point-in-time copy of all the files and directories that were in the volume by the time the snapshot was taken

the snapmirror snapshots should match with the equally-named snapshots on the DP system, but it's possible that the others don't match, depending on your snapmirror policy (whether you do a 1:1 copy, in which case you should have the exact same snapshots on the destination as on the source, or whether you do snapvault, where you can have more snapshots on the destination than on the source for backup purposes)

[gentle tulip]

just to summarise .snapshots on the primary volume will be holding

• snapshots of its own under daily.* and snapshots.*
• will hold snapshots for the backup volume under snapmirror.* directory.

is there any formula for forecasting space usage in this case. If lets say I have 100GB volume off netapp and this volume now migrates to NETAPP with snapshots and snapmirrors. What should be the storage allocation? I am running into issues where snapshots are overruning the entire volume with no space for user data.

[whole swallow]

no. it will only show what's on the current system. to see the actual data on the backup destination, you would have to connect via CIFS to the secondary system.
BUT the content of the snapshots will be the same (depending on the policy used, i.e. what I wrote above)

the size of a snapshot only depends on the rate of change of the data (at a 4k granularity level). if your data is 100gb, and it changes daily, every "daily" snapshot will be around 100gb in size. if only 1gb of that data changes daily, your daily snapshots will be 1gb in size

if your snapshots are growing too fast you have a higher than expected rate of change. you can either reduce the number of snapshots kept (e.g. go from 4 weeks to 2 weeks) or you can increase the volume size (if you have space in the aggregate). If you use SnapVault you can reduce the number of snapshots taken on the source, and instead keep more snapshots on the destination

however that means that your users cannot restore older versions of files (e.g. through the "previous versions" tab in the explorer) themselves but have to either connect to the backup destination or open a ticket with your service desk to have files restored that are no longer kept on the primary system