#Move Data From StorageGrid

1 messages · Page 1 of 1 (latest)

vestal dew
#

So I was reading this near 4 year old article and wanted to see if this still applies - https://community.netapp.com/t5/Object-Storage/force-data-on-StorageGRID-to-move-back/td-p/157356

Since generally when you perform a volume move you are moving a volume to either a new SVM or Aggregate.

It this still a legitimate process to run the volume move command with the "-tiering-policy none" and the data will move from SG back to local storage?

I assume this article is providing the same outcome but without the volume move command - https://docs.netapp.com/us-en/ontap/fabricpool/promote-file-system-data-performance-tier-task.html

force data on StorageGRID to move back?

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 m...

Promote file system data to the performance tier

You can proactively retrieve active file system data from a restored Snapshot copy in the cloud tier and promote it to the performance tier.

loud knoll
#

That's exactly what I would try to force the data back to the local tier

#

please be aware, that there is no force-remove of the fabricpool tier for the aggregate, if you really want to get rid of it, you have to create a new aggregate and vol move all volumes

sand thicket
vestal dew
#

Thank you both for the feedback and information!

vestal dew
#

@loud knoll You mean you would try both steps in both articles or is one more accurate then the other to you?

loud knoll
#

Tiering Policy None, then you could do either vol move or Set the Cloud retrieval to promote

vestal dew
#

@Olli Got it thanks!

trim magnet
#

I thought about creating a new thread, but what I have sort of fits in here.

I have two Grid connected aggregates and two that are not. This helps me manage volumes in a svmdr destination that have tiering policies at the source that are undesirable at the destination.

Recently, I moved several hundred TB of data out of the Fabric Pool aggregates but did not see any redution in usage on our grid. I have increased the threshold for -unreclaimed-space-threshold and still haven't seen any reduction in usage.

Has anyone done either of the above? What is a safe threshold? Do I need to be doing something different?

loud knoll
#

your aggregate has to be filled up to tiering-fullness-threshold (at least) before any data goes out to fabric pool

trim magnet
#

Yeah, it's already in the grid. I've moved volumes out of grid connected aggregates and the tiered data doesn't look like it's being reclaimed.

wispy light
#

I don't remember if it can be forced or not. The FabricPool background scanners can be slow to move large quantities of data. For example, a promote today isn't fast and requires a volume move with no tiering policy on the new aggregate to make it reclaim faster.

vestal dew
#

@wispy light Thanks for the feedback

wispy light
#

Yw