This keeps overheads on the virtual environment and network to a minimum. It is also recommended combining this with the proxy role if backup from Storage Snapshots is possible. In general, we recommend whenever possible to use physical machines as repositories, in order to maximize performance and have a clear separation between the production environment that needs to be protected and the backup storage. There are tools also to defragment XFS, but they should be used with caution as it takes a long time for the procedure to complete and they generate a heavy performance hit. XFS has its own ways to mitigate fragmentation, like creating speculative preallocations when copy on write, but in order to keep performance from degrading it’s important to have an array with a good random read performance, or even better use SSDs. Fragmentation affects negatively read performance, and even those reads that would normally be sequential will basically become random operations. One known issue that requires attention is fragmentation of the XFS filesystem, which is inevitable as clone operations are executed regularly. You can also consider XFS/Fast Clone if your data is encrypted, as Veeam will know which metadata/datablocks inside the encrypted backup-files correspond to which source-datablocks. Using LVM with XFS is fine if you need more flexibility for volume extension. It also does not have any impact on Veeam’s RAID stripe size recommendation, because the filesystem block size is just how granularly the filesystem tracks block allocation. The Linux implementation of XFS is limited to a maximum of 4K for the block size this shouldn’t be an issue as the filesystem size can go up to 1PB and performance is not affected by the small block size.
#VEEAM BACKUP FROM STORAGE SNAPSHOTS FULL#
Since all transformation tasks are done via metadata operations, synthetic full backups get a huge performance boost and they don’t take up any additional capacity. Veeam leverages it to implement the Fast Clone functionality. XFS Data Block Sharing (Reflink) provides the same benefits as ReFS in terms of speed and space consumption. Please see the full list of operations that consume task slots at the bottom of this page. For this reason it’s recommended to use thick provisioned LUNs with ReFS.
Depending on the ReFS size or task requirements you may want to add up more memory but there should be no need to go over 256 GB.Ī word of caution about ReFS file systems and thin provisioned LUNs: ReFS does not support trim, unless on storage spaces, so space reclamation will not take place. 128GB of RAM are often sufficient for task, OS and ReFS requirements if the total ReFS volume size of the server is below than ~200 TB. However, you don’t have to scale this indefinitely. For ReFS based file systems the recommendation is to add 0.5 GB RAM per TB of ReFS storage. For example:Īlways use 64 KB block allocation size. The quantity of cores required can be calculated by dividing the proxy core count by 3.
#VEEAM BACKUP FROM STORAGE SNAPSHOTS WINDOWS#
Backup Repository HA using Windows Storage Replica.
0 kommentar(er)
