Hardened (Immutable) Repository
Hardened backup repository is a backup repository with an option for switching on immutability. Immutability protects your data from loss as a result of malware activity by temporarily prohibiting the deletion of data. It can be switched on while adding a backup repository, at the Configure Backup Repository Settings step of the wizard.
Currently, only Linux backup repository provides the immutability option.
The backup files become immutable for the period indicated at the Configure Backup Repository Settings step of the adding backup repository wizard. To learn more about the immutability settings for Linux, see How Immutability for Linux Works.
Supported Job Types
Hardened backup repository supports backup files created with the following types of jobs:
- Backup jobs and backup copy jobs
- Backup copy jobs from external repositories (Veeam Backup for Azure, AWS and Google)
- Veeam Agent backup
- Standalone full backup
- vCloud Director
- VeeamZIP backup
- Nutanix AHV
Other types of jobs, including NAS backup, log shipping, RMAN/SAP HANA/SAP on Oracle backup, and backup copy jobs from all the above-mentioned, can also be targeted to the hardened repository, but then it will act as a simple repository: the immutability option will not apply to the backup files created with such jobs.
All the requirements and limitations for Linux backup repository apply to hardened repository. In addition, the following considerations and limitations apply:
- Immutability retention overrides job retention: if the job retention period is shorter than the immutability period, Veeam Backup & Replication will not delete the backup files when the retention period is over, but only when the immutability period expires.
- If immutability is switched on, you will not be able to delete immutable backup files manually.
- For backup copy jobs, set up GFS retention policy. Otherwise, you will not be able to use the immutability feature. For more information, see Long-Term Retention Policy (GFS).
- To use the immutability feature, select forward incremental backup chain with active full backup or synthetic full backup when configuring the jobs.
- Hardened repository requires Veeam Data Mover Service. For security purposes, the rights of Veeam Data Mover Service are reduced: SSH Connection is necessary only for deployment of Veeam Data Mover Service to the Linux host. For more information, see Specify Credentials and SSH Settings.
- Due to Veeam Data Mover Service requirements, Linux host version must be 64-bit.
- When configuring a hardened repository, you can use either persistent or single-use credentials. For more information, see Specify Credentials and SSH Settings.
If you use single-use credentials, the host where the hardened repository resides cannot have any other role: you cannot add it as a proxy or as a file server.
If you use persistent credentials, the host where the hardened repository resides cannot have the proxy role, and the file server role is not recommended.
- You can place both hardened repositories and classic repositories on one Linux server only if you have used single-use credentials when adding the host.
- Linux host file system must support extended attributes modified by chattr and setfattr. For more information, see these Linux articles: lsattr, attr .
- [For Nutanix Mine] It is not recommended to switch on the repository immutability for the Nutanix Mine infrastructure. As Mine repositories contain thin provisioned disks, there may be the case when Veeam Backup & Replication uses full storage capacity of the repository and is not able to delete backup files from the file system.
Deployment of Hardened Repository
We recommend the following best practices for adding a hardened repository:
- When adding the Linux server, use temporary credentials. To do that, click Add and select Single-use credentials for hardened repository at the SSH Connection step of the New Linux Server wizard.
- Within the user account that you plan to use to connect to the Linux server, select the Elevate account privileges automatically and the Use "su" if "sudo" fails check boxes. For more information, see Linux Accounts (User Name and Password).
- Create a separate folder for the hardened repository. Allow access to this folder only for the account that you plan to use to connect to the Linux server.
Use the following commands:
- To create the folder:
- To assign the folder's owner:
chown -R owner:group <folder_path>
- To allow access to the folder only for its owner and root account:
chmod 700 <folder_path>
where <folder_path> — path to the folder you are creating.
Both owner and group can be the account that you plan to use to connect to the Linux server.
- After you have added the host (for single-use credentials) or the repository (for persistent credentials), disable SSH connection for the account that you plan to use to connect to the Linux server. If you can work with the server from the console, disable SSH connection for the server itself.
Adding Hardened Repository to Scale-Out Backup Repository
You can mix both immutable and non-immutable repositories within one scale-out backup repository. In this case, only the backup files on the immutable extents will be protected with immutability.
If you use the capacity tier option, keep in mind that having immutable repositories as performance extents will affect the capacity tier behavior. You will not be able to move the 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 period is over, Veeam Backup & Replication will be able to 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 immutability of the target extent will apply to the copied backup files. For more information on evacuating backups, see Evacuating Backups from Performance Extents.