Click the Exhibit button.
You have a NetApp AFF A400 HA pair with Fabric Pool enabled on all data using the snapshot-only policy. Users are reporting slow restores when they recover files with the Windows Previous Versions tab.
Referring to the exhibit, what is the highest latency seen on restore?
The highest latency seen on a restore operation is associated with the GET operations, as these represent file retrieval actions. Among the listed GET operations, the maximum latency values are 9591 ms for 4 KB size, 10021 ms for 0 KB size, 7009 ms for 32 KB size, and 7838 ms for 256 KB size. The highest latency value among these is 10021 ms, making it the correct answer.
I would say is B, doing a restore , the user retrieve files, which is a GET operation. You can use the S3 GET Object request to retrieve an object from an S3 bucket. https://docs.netapp.com/sgws-113/index.jsp?topic=%2Fcom.netapp.doc.sg-s3%2FGUID-8B7BB6D4-FA59-4E82-BEAC-45DA8C642029.html
I agree as well. B should be the correct answer: Restore Operations: GET Client Hierarchy, GET Subclient Browse, GET Exchange DAG Recovery Points, GET Microsoft SQL Server Instance Browse, GET Microsoft SQL Server Backup Job
For me it's a tricky question. The screenshot is the result of: "storage aggregate object-store profiler show" Object store profiler results are a measurement of connectivity between ONTAP and the cloud tier object store by using 4MB PUT operations and byte-ranged GET operations ranging from 4MB to 256KB. (Only internal ONTAP features, such as SnapMirror, can make use of 256KB GET operations, third-party clients cannot.) https://www.netapp.com/media/17239-tr4598.pdf The test do a Put AND a Get, and both are over 10000ms (FabricPool can tolerate latencies as high as 10 seconds) I would say is B, because the screenshot show a latency over 10000 and 9 failure.
Such a trick question. Make sure you look at the entire screen aka PUT, GET.
I say D, 9591 for only 45MB around.
Yup, GET commands literally get objects from object storage.
I would say the answer is B. because the size of the transferred data is 0 while many times it is requested.
Snapshot restore operation overwrites the existing data so wouldn't this be a PUT operation and not GET?
B, I agree as well.
Isn't it D? Set to Snapshot-policy, so only snapshots are tiered. Snapshot blocks are 4K in size.