destination snapmirror space issue

[lebedevanton]

hello everyone,

Im running into an issue on my target filer where an aggregate is running extremely low on disk, and adding disks at this time is not an option to expand space.

Is it possible for me to manipulate space on the volumes that are snapmirrored to give back some space to the aggregate?

Here is an example output of my system;

when I do aggr show_space -g aggrname i get this out put

Aggregate                       Allocated            Used           Avail

Total space                       11298GB         3856GB           652GB

and the volumes look like this

Volume                                    Allocated            Used       Guarantee

exchange1_system                    76GB            28GB          volume

exchange1_snapinfo                 182GB           106GB          volume

exchange1_db2_sg2                  522GB           214GB          volume ( its only using half of the space allocated)

exchange1_db2_log2                 130GB            46GB          volume

I tried to resize the disk but snapmirror complains that it needs the disk to be the same size as with source.

do I need to size the source volumes to be smaller for this work ? is there any other way to get my snapmirror destination volumes to be smaller in size without manipulating size of the volumes on source?

[rwelshman]

The destination volume has to be equal or greater than the source in order for the snapmirror to occur.

[lebedevanton]

how can I adjust my volumes to save some space ?

[radek_kubka]

Quick fix:

Make destination volumes bigger, but use thin provisioning (space reservation set to none).

Regards,

Radek

[shaunjurr]

Hi,

You haven't really said what it is that you are mirroring, even if it is hinted at with the volume names.

With normal unstructured data and Qtree Snapmirror, it is all fairly simple.  Just turn off the volume guarantees and run "sis" on the volumes (space savings come first when the "pre-sis" snapshots expire.

With Volume Snapmirror, you basically need to have the same sizes on the source and destination and many of the volume options are "replicated" to the destination, so adjusting space reservation or volume guarantees is a matter of setting them on the source.

If you are mirroring LUN (block) data, then deduplication on the source is probably not going to be ideal in many cases and not possible on the destination, if I remember correctly.  If you thin provision LUN volumes on the source (turn off volume guarantees and space reservation) and follow the Best Practices (vol autosize, etc), then you will see the savings on the VSM (Volume Snapmirror) again when the "pre-sis" snapshots "roll out" (expire).

There's a TR on thin provisioning.  It works as long as you adjust your volume sizes automatically (irregular snapshot growth) and keep your aggregates from going full... 90% is basically full if you expect any performance.

[radek_kubka]

With Volume Snapmirror, you basically need to have the same sizes on the source and destination and many of the volume options are "replicated" to the destination, so adjusting space reservation or volume guarantees is a matter of setting them on the source.

Well, not exactly.

During normal operation source & destination may have different properties, e.g. source is fat, destination is thin. Only when fail-over occurs, the destination inherits properties of the source. The key problem is when source volume is grown (auto or manually), the destination won't grow on its own & replication may fail if source becomes bigger than destination.

[baijulal]

There are some considerations to be made,

please refer "Online backup and recovery guide" for your version of ONTAP available on now site and read the "resizing a SnapMirror source and destination volume pair".