force data on StorageGRID to move back?

[adf]

How do I guarantee data that has been moved to the capacity tier can get moved back to the performance tier? It appears that what's in the documentation is not entirely correct.

Suppose my boss comes in tomorrow and tells me, "We're getting rid of FabricPool/StorageGRID next week, so you need to move all data back." I'm not seeing how this is possible.

https://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.dot-cm-psmg%2FGUID-149A3242-B120-49CB-B712-BDDED53ED25D.html

The above suggests if I change one from 'auto' to 'none' that all data will be kept on the performance tier. But I called in because it wasn't working, and the guy told me to change it to 'snapshot-only' instead and it would move it back. But now that's it's already been moved to 'none,' how do I get the data back? Changing it to 'snapshot-only' doesn't return it. It seems my data is captive to SG with no way to return it. Yes, I am doing vol moves after changing the tiering type.

This is very frustrating.

[Ontapforrum]

Hi,

We haven't implemented Cloud Tiering yet but I was compelled to read about 'fabric-pool/storage-grid' after going through your email and this is what I observed.

In the fabric-pool documentation, it clearly states that - "Moving blocks back to the performance tier is not allowed."

FabricPool Documentation clearly states : "Changing the tiering policy from auto to snapshot-only or none does not cause active file system blocks that are already moved to the cloud tier to be moved back to the performance tier." In other words, once moved you cannot moved it back via 'changing policy'.

As I read, the only way to bring back (Inactive/cold Data-blocks) is either 'reads' or 'vol-move': As long as cloud-tier exists, "Volume reads" are needed for the data to be moved back to the performance tier. Which as I understand, unless the already moved blocks in the 'Cloud-Tier' are "read again", they will not come back to Performance tier.  Interestingly,  b'cos we are dealing at 'blocks-level' and not file-system level, we cannot decipher which folder/files are pointed to which blocks and therefore you have no control over which directory/file to "read-simulate" in order to bring those blocks back.

Another method is 'volume-move' (which I believe you have resorted to), Page:16 (Please read/something to watch out for) on this tr-4598 covers good info around 'volume-move' destination tier based on given 'tiering policy'.

Above information is based on the following documents:
https://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.dot-cm-psmg%2FGUID-149A3242-B120-49CB-B712-BDDED53ED25D.html
https://www.netapp.com/us/media/tr-4598.pdf
https://whyistheinternetbroken.wordpress.com/tag/fabricpool/

Thanks!

[adf]

That's the issue -- they are not going back even when I do a vol move after changing the tiering policy.

So what's happened is we're running out of space on the GRID. But nothing so far (changing from 'auto' to 'none' & doing a vol move, changing from 'auto' to 'snapshot-only' and doing a vol move, etc.) will move anything back. Reading all data in a volume is not exactly an option.

[adf · Accepted solution]

So here's what it was:

You cannot change the tiering policy ahead of the move, it must be a part of the move. So a vol modify followed by a vol move will not work. It must be a single vol move that changes the tiering policy as part of it.

[manistorage]

volume move start -  use the -tiering-policy parameter to specify the tiering policy for the volume. this will move teh volume out of fabric pool.

Regards,

Mani