rebuilding the Linux Harden repository in the event of a DR

[Danh3]

Hello Community,

Nimble storage and present vols to the Linux hardening repository via iSCSI for backup storage

Questions regarding rebuilding the Linux Harden repository in the event of a disaster:


If this Linux server OS crashed/hit by ransomware, requiring the OS to be rebuilt and subsequently reconnect to the original Nimble backup storage and remount storage vols to the file system, will the veeam immutable settings/retention for the old backup data remain intact, or will these settings(immutable bit 'i' or retention) be lost?

If the immutable settings/retention are lost, will it be necessary to manually execute a Veeam PowerShell script to reapply the immutable attribute or retention settings to the old backup data? If so, once the immutable attribute is manually added, will all the old backups now adhere to the new immutable retention settings and age off automatically based on the newly applied retention settings?

After the Linux hardening storage has been rebuilt, to ensure that browsing and restoring functions work correctly, will it be necessary to mount the Nimble volumes (backup storage volumes) with the same name as the old mount point (e.g. old mount point /mnt/imm-vol1)?

Additionally, how does the browsing and restore determine which path to search for in order to retrieve the data? Where is the veeam backup metadata stored, including information about the backup data path and filenames, to facilitate the browsing and restoration process?

thanks

[Mildur]

Hello Dan

will the veeam immutable settings/retention for the old backup data remain intact, or will these settings(immutable bit 'i' or retention) be lost?

immutability flag is directly set on files in the filesystem. Mount it to a new Linux server and the files are still immutable.

After the Linux hardening storage has been rebuilt, to ensure that browsing and restoring functions work correctly, will it be necessary to mount the Nimble volumes (backup storage volumes) with the same name as the old mount point (e.g. old mount point /mnt/imm-vol1)?

Mount point doesn't matter. But it may be easier for you if you use the same mount point.

Additionally, how does the browsing and restore determine which path to search for in order to retrieve the data? Where is the veeam backup metadata stored, including information about the backup data path and filenames, to facilitate the browsing and restoration process?

Backup Metadata is stored side by side with the backup files on the repository.
Addionally, information about the failed repository is stored in the Veeam configuration database. You will not need this information anymore. It can be removed from the configuration database after you have followed the next steps:
1.) Install the new linux server
2.) Mount the volume with the backups
3.) Add the new linux server to the backup server with the path of the backups.
4.) Rescan the repository to update the backup server configuration database with the backup files on the new repository server
5.) Map your jobs to the backup files on the new repository server
6.) Test your backup jobs and data recovery from previous restore points.

Best,
Fabian

[Danh3]

thanks @Mildur

You've addressed my inquiries.