Hi,
Answering your last post:
"So the below linkage exactly supports our issue as best i can tell (and REFS is a VEEAM best practice)"
You are right, we never doubt the configuration. veeem's best practices have nothing to do with your space reclamation problem. In essence the problem is microsoft disabling the UNMAP feature in the REFS file system.
when you have time use the veeam best practices site to validate your configuration:
https://bp.veeam.com/vbr/VBP/3_Build_structures/B_Veeam_Components/B_backup_repositories/block.html#refs
ReFS
ReFS is using linked clone technology. This is perfect for synthetic operations and will save dramatic IOs and throughput during operations like merges or creating synthetic fulls.
Follow these best practices when using ReFS:
- Format the volume with 64KB block size
- Configure 256 KB block size on LUNs (Storage or RAID controller)
- Never bring linked clone space savings into your calculation for required storage space
- “All ReFS supported configurations must use Windows Server Catalog certified hardware” - please contact your hardware vendor
- Never use any shared LUN concept with ReFS and a Veeam Repository
- Check the existing driver version of ReFS:
- The minimum should be ReFS.sys 10.0.14393.2457 on Windows Server 2016.
- The minimum should be ReFS.sys 10.0.17763.1369 on Windows Server 2019.
- General recommendation: fully patched with the most recent Windows Updates.
Could you explain what you mean by this statement?
"Bat as its presented as a mapped drive it cant "see through it" if that makes any sense. We also tried with Disk ID each time it does not detect it as a NetApp disk."
"We also tried the below.
HOW TO RECLAIM SPACE FOR THIN PROVISIONED LUNS USING POWERSHELL FOR WINDOWS… – One thing (wordpress.com)"
The command mentioned in the article "Invoke-NaHostVolumeSpaceReclaim" is for ontap 7mode storage. Even if you use the correct option "Invoke-NcHostVolumeSpaceReclaim", the host operating system and the file system need to support the UNMAP capability (SCSI thin provisioning features).
Host support for SCSI thin provisioning
https://docs.netapp.com/ontap-9/topic/com.netapp.doc.dot-cm-sanag/GUID-882DF278-68F2-49DF-AB60-5264DC962864.html
When I try to run the cmdlet the following is returned:
Identifying the netapp lun:
PS C:\Users\administrator> get-disk | Select-Object Number,FriendlyName,OperationalStatus | Where-Object {$_.FriendlyName -eq "NETAPP LUN C-Mode" }
Number FriendlyName OperationalStatus
------ ------------ -----------------
1 NETAPP LUN C-Mode Online
PS C:\Users\administrator>
Identifying the volume in windows:
PS C:\Users\administrator> Get-Volume | Where-Object {$_.FileSystem -eq "Refs"}
DriveLetter FileSystemLabel FileSystem HealthStatus SizeRemaining Size
----------- --------------- ---------- ------------ ------------- ----
E DATA ReFS Healthy 4.88 GB 19.81 GB
PS C:\Users\administrator>
Executing the cmdlet:
PS C:\Users\administrator> Invoke-NcHostVolumeSpaceReclaim e:
Invoke-NcHostVolumeSpaceReclaim : DeviceIoControl failed (FSCTL_GET_NTFS_VOLUME_DATA)
At line:1 char:1
+ Invoke-NcHostVolumeSpaceReclaim e:
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Invoke-NaHostVolumeSpaceReclaim], Exception
+ FullyQualifiedErrorId : Could not get volume info,DataONTAP.PowerShell.SDK.Cmdlets.Windows.InvokeNaHostVolumeSpaceReclaim
PS C:\Users\administrator>
As the error indicates, this command is only compatible with NTFS.
"Invoke-NcHostVolumeSpaceReclaim : DeviceIoControl failed (FSCTL_GET_NTFS_VOLUME_DATA)"
The cmdlet help says:
get-help Invoke-NcHostVolumeSpaceReclaim
"This cmdlet examines the NTFS file system on a Windows volume, locates all free space, and deallocates the corresponding blocks on the Data ONTAP storage controller. No difference is apparent from Windows' perspective, but all space not consumed by files on the volume is freed on the storage controller."
Hope this helps!
