# Veeam Immutability Configuration Guide

## Overview

Veeam immutability is a data protection feature that prevents backup files from being modified or deleted for a specified retention period. This is critical for ransomware protection and compliance.

## Supported Repositories

Immutability is supported on the following repository types:
- Linux hardened repository (native immutability via file attributes)
- Object storage (S3 Object Lock, Azure Blob Immutable Storage)
- Scale-Out Backup Repository (SOBR) with capacity tier

## Linux Hardened Repository Setup

### Prerequisites
- Linux OS with chattr -i attr option - recommended Redhat, Rocky OS, or Ubuntu 20.04 or later 
- XFS filesystem (recommended for fast clone veeam feature support)
- Block level DAS or iSCSI (or similar block level protocol) storage required for immutability
- Dedicated non-root user for Veeam transport service (this used to be optional but recommended; with Veeam Hardened Repository via VIX on VSA its required and has been required since late V12 - i.e. the account that authenticates with VBR and allows veeam to install software on linux box is a temp elevated account that is not root or sudoer equivalent after initial setup.
- SSH access for initial configuration only - By late V12 or V13 this is automated but good to understand best practice.

### Configuration Steps (NOTE: This is for DIY Veeam Hardened Linux Repository; almost anyone would use the VIX auto installer or the VHR if on later V12 versions):

1. Format the backup drive with XFS filesystem
2. Create a dedicated Veeam service account (temporary elevated root then regular user after auth and install from vbr)
3. Configure sudo permissions for the transport service
4. Add the repository in Veeam Backup & Replication console
5. Enable "Make recent backups immutable" and set retention period
6. Disable SSH after initial setup for maximum security

### Immutability Flags

Veeam uses the Linux `chattr +i` (immutable) attribute on backup files. Once set:
- Files cannot be modified, renamed, or deleted
- Even root cannot remove the immutable flag during the retention period
- The Veeam transport service manages flag lifecycle automatically

## Object Storage Immutability

### S3 Object Lock
- Enable Object Lock on the S3 bucket at creation time
- Veeam uses Compliance mode (not Governance) for true immutability
- Set default retention via Veeam, not bucket policy
- Ensure versioning is enabled (required by Object Lock)

### Azure Blob Immutable Storage
- Enable immutable storage at the container level
- Use time-based retention policies
- Veeam manages retention periods via API calls

## Best Practices

- Set immutability period to at least your retention period; there is an argument that "long immutability" or 90+ days prevents "sleeping malware" from being restored from backup.
- Use Linux hardened repository for on-premises deployments and S3 immutability (Veeam Data Cloud Vault is our native offering for this at Veeam but many options)
- Combine with 3-2-1-1-0 backup rule (3 copies, 2 media types, 1 offsite, 1 immutable, 0 errors)
- Test restore procedures regularly — immutability protects against deletion, not corruption
- Monitor repository health via Veeam ONE alerts or VDC dashboard if using Vault

## Troubleshooting

### Common Issues
- "Immutable flag cannot be set": Check Permissions, Storage format/protocol, XFS filesystem and firewall/network path
- "Object Lock not enabled": Must be set at bucket creation time, cannot be added later (almost always true)
- "Retention period conflict": Veeam retention must not exceed Object Lock maximum

### Verification
Use `lsattr` command to verify immutable flags on Linux:
```
lsattr /mnt/backup/*.vbk
```
Expected output shows 'i' flag for immutable files.