Limitations and Considerations
All requirements and limitations for a Linux backup repository apply to a hardened repository. In addition, mind the following limitations and considerations.
Hosts and File Systems Requirements
- Due to Veeam Data Mover requirements, the Linux host version must be 64-bit.
- Linux host file system must support extended attributes modified by the chattr and setfattr commands. For more information, see these Linux articles: lsattr, xattr.
Common Linux file systems support these attributes (XFS, EXT3 / 4, BTRFS). We recommend XFS for the hardened repository for performance and space efficiency reasons (block cloning support).
- ReiserFS file system does not support immutable files. You cannot select a Linux server running on ReiserFS as a hardened repository with immutability.
- To support Linux server with the NIST 800-171 security profile, make sure the requirements listed in this Veeam KB article are met.
Limitations for Repositories
- The hardened repository cannot be shared between different Veeam Backup & Replication servers.
- If you want to store backup files in a repository with immutability, you cannot select a reverse or a forever forward incremental backup mode. Once a backup file becomes immutable, it can be merged or deleted only when the immutability time period expires. For this reason, you must enable active full backup or synthetic full backup in the backup job settings.
The requirement for periodic fulls also means that XFS-based repository is more preferable from a disk space usage perspective because thanks to fast cloning, synthetic full backups take no physical disk space (except for metadata).
- You cannot delete immutable backup files manually from a hardened repository.
- When configuring a repository with immutability, you can use either persistent or single-use credentials. For more information, see Specify Credentials and SSH Settings. But the corresponding Linux host should not be used twice in the database:
- If you use single-use credentials, the host where the repository resides cannot have any other role. This includes the proxy, file server, gateway server, etc.
- If you use persistent credentials, the host where the repository resides cannot have the proxy role, and the file server role is not recommended.
- NFS does not accept immutability commands from Linux. Due to this, mind the following:
- You cannot use an NFS Share as a repository with the immutability.
- You cannot use an NFS volume mounted on a Linux server as a hardened repository with immutability (needs to be Local or DAS). You can use an NFS volume mounted on a Linux server as a hardened repository without immutability.
- You can place both repositories (hardened and standard) on one Linux server only if you used single-use credentials when adding the host. Standard repository is a repository added with persistent credentials and disabled immutability.
- For a scale-out backup repository:
- You can add a hardened repository to your scale-out backup repository as a performance extent. For more information, see Scale-Out Backup Repository and Add Performance Extents.
- If you use the Capacity Tier option, keep in mind that having a hardened repository with immutability as a performance extent will affect the Capacity Tier behavior. You will not be able to move immutable backup files, because they cannot be deleted from the performance extent. Veeam Backup & Replication will copy such backup files to the Capacity Tier. When the immutability time period is over, Veeam Backup & Replication will delete these files from the performance extent. For more information on copy and move policies, see Copying Backups to Capacity Tier and Moving Backups to Capacity Tier.
- If you evacuate your backups from an immutable performance extent, Veeam Backup & Replication will copy them instead of moving. If the target extent is also immutable, then the immutability of the target extent will apply to copied backup files. For more information on evacuating backups, see Evacuating Backups from Performance Extents.
- We recommend to avoid mixing mutable and immutable extents within one scale-out backup repository. You can mix them only during migration scenarios when you want to make a hardened repository from an existing Linux extent.
- An immutability retention overrides a job retention: if the job retention period is shorter than the immutability period, Veeam Backup & Replication does not delete backup files when the retention period is over, but only when the immutability period expires.
- For importing a backup, we recommend to use VBK backup files. Metadata files of a backup chain (.VBM) cannot be immutable because they are updated on every job pass.
- For backup copy jobs, enable the GFS retention policy. Otherwise, you will not be able to use the immutability feature. For more information, see Long-Term Retention Policy (GFS).
- If a hardened repository with immutability is a part of a scale-out backup repository with the capacity tier added, the immutability time period for full backup files with GFS retention policy is set according to the following:
- [For capacity tier with disabled move policy] Veeam Backup & Replication compares the immutability period of the backup repository and the GFS backup file lifetime, and sets an immutability period for full backup files with GFS retention policy as equal to the longest of these periods.
For example: the backup repository immutability period is 10 days; the GFS backup file lifetime is 3 years; the backup file will be immutable for 3 years; the increments from this full backup file will be immutable for 10 days from the moment of the last increment creation.
- [For capacity tier with enabled move policy] Veeam Backup & Replication ignores the GFS retention policy. The immutability time period for full backup files equals the period specified in the setting of a hardened repository.
- If a hardened repository with immutability is a part of a scale-out backup repository (with the capacity tier added and enabled move policy) and is used as a target for VeeamZIP jobs — the immutability time period for backup files equals the period specified in the setting of a hardened repository.
- The immutability feature is supported for image-level backups only. You can use a hardened repository to store NAS backups, transaction backups, RMAN/SAP HANA/SAP on Oracle backups, but you cannot use the immutability feature to protect these backups.
- We do not recommend to use the immutability feature for a Nutanix Mine infrastructure. As Mine repositories contain thin-provisioned disks, there may be the case when Veeam Backup & Replication uses full storage capacity of a repository and is not able to delete backup files from the file system.
- The immutability time period for backup files produced with VeeamZIP or Export Backup jobs is set according to the following:
- [With enabled retention period] Veeam Backup & Replication compares the immutability period of the backup repository and the retention period lifetime, and sets an immutability period for backup files with retention period as equal to the longest of these periods.
For example: the backup repository immutability period is 1 month; the VeeamZIP or Export Backup backup file lifetime is 7 years; the backup file will be immutable for 7 years.
- [With disabled retention period] Veeam Backup & Replication ignores the VeeamZIP or Export Backup retention period. The immutability time period for backup files equals the period specified in the setting of a hardened repository.
Hardened Repository Availability
Veeam Backup & Replication does not store singe-use credentials in the configuration database. Thus, if you backup Veeam Backup & Replication configuration database and restore settings of Veeam Backup & Replication, a hardened repository becomes unavailable in the Veeam Backup & Replication console. To make a repository available again, do the following after restore:
- In the Veeam Backup & Replication console, open the Backup Infrastructure view.
- In the navigation pane, select Managed Servers.
- In the working area, right-click the Linux server used as a hardened repository and select Properties.
- At the Step 3. Specify Credentials and SSH Settings of the Edit Backup Server wizard, use single-use credentials and click Finish to update settings.