7.1 Restoring from Insider Threat Protection
Files deleted from a Cloud Repository are placed into the “Recycle Bin” folders created by Insider Threat Protection. Once an attack has been stopped and a tenant needs his files back to start a restore, it’s up to the service provider to move those files from the Bin to the original location so that the tenant can see them and use them.
Restore deleted files
Veeam Backup & Replication moves to the Recycle bin only VBK and VIB files. VBM files are deleted from disk immediately when a tenant deletes a backup or a backup file is automatically deleted from the backup chain according to the retention policy. As a result, the service provider cannot simply move a backup file back to the folder where tenant’s backups are stored on the cloud repository. Instead, the service provider and tenant need to follow this procedure:
- The tenant contacts the service provider requesting a restore from a deleted backup.
** IMPORTANT!** Before restoring data from a deleted backup, the tenant must make sure that there are no VBM files with metadata about this backup in the cloud repository. If a tenant needs to restore data from a deleted backup file pertaining to a backup that still exists on the cloud repository, the tenant must delete this backup prior to importing a VBK file in the tenant backup console.
The service provider finds one or more backup files required for restore in the Recycle bin and passes them to the tenant, for example, over the network or on a portable drive.
The tenant imports the VBK file(s) in the Veeam Backup & Replication console on the tenant backup server.
After successful import of a backup, the tenant can restore data from the backup in a regular way.
[Optional] The tenant may want to continue the backup chain started with the obtained backup file(s). This operation can be available depending on multiple conditions. For details, consider submitting a support case to the Veeam Support Team.
The reason for sending data to the tenant instead of just moving them into the original location is the backup encryption. If files are encrypted, the tenant needs to import them using their own Veeam environment.
This is a quick recap of the possible choices and their advantages:
|Server for Import||Pros||Cons|
|1. Tenant’s VBR. (Default)||Current encryption passwords are picked up||Need to transfer backup files all the way back from SP to tenant. The procedure must be strictly followed, otherwise database issues are expected with the backup chain presence on both sides. New restore points will be gone.|
|2. New tenant’s VBR (for those tenants on version older than 9.5u3)||no DB issues, can preserve new restore points (in the separate chain)||need to transfer files, need to know passwords|
|3. New SP’s VBR (good for non-encrypted backups)||no need to transfer files||service provider needs to know encryption passwords|
Retrieve files from Capacity Tier
Under regular conditions, providers and tenants don’t have to worry about moving manually data to and from the Capacity Tier. All the needed operations are completed automatically by SOBR algorithms, by pulling down for example the needed blocks from the Capacity Tier if they are not available in the Performance Tier.
There may be however situations where a service provider needs to manually retrieve files from the Capacity Tier; for example, when one of the files that has been saved by Insider Threat Protection has also been moved previously into the Capacity Tier, like described in chapter 3.8 and picture 3.28, and it’s part of an encrypted backup job.
In order to retrieve a file from the Capacity Tier, the provider first lists the files that have been moved to the Capacity Tier, using powershell:
Get-VBRDeletedDehydratedBackupFile Path Name Id ---- ---- -- E:\Backups\_RecycleBin\test\Backup_Copy_to_VCC\vm-470.17fcD2018-12-03T030029_W.vbk vm-470.17fcD2018-12-03T030029_W.vbk c1e25df6-2fa0-4f88-96dc-6b5f429e1acb E:\Backups\_RecycleBin\test\Backup_Copy_to_VCC\vm-726.0fbdD2018-12-03T030029_W.vbk vm-726.0fbdD2018-12-03T030029_W.vbk e1f67d9c-9097-4dc0-91d4-31e7caa5b3ee E:\Backups\_RecycleBin\test\Backup_Copy_to_VCC\vm-470.17fcD2018-12-09T033710_W.vbk vm-470.17fcD2018-12-09T033710_W.vbk 39b67012-1bcb-4bb1-8947-58ce049e6c07 E:\Backups\_RecycleBin\test\Backup_Copy_to_VCC\vm-727.a2a2D2018-12-09T033710_W.vbk vm-727.a2a2D2018-12-09T033710_W.vbk 83c2c887-5b73-4ec4-8de3-76977f476314 E:\Backups\_RecycleBin\test\Backup_Copy_to_VCC\vm-726.0fbdD2018-12-09T033710_W.vbk vm-726.0fbdD2018-12-09T033710_W.vbk 1b92ad13-8427-4fde-bd09-09b611916878
The command gives us the list of the VBK files that are stored into the Recycle Bin in a Dehydrated state. You can see in the following screenshot that those files are only 20MB is size:
7.1: The file is dehydrated and moved into the Recycle Bin
Let’s suppose we want to retrieve vm-727, in its restore point of 09-12-2018. The file we need is vm-727.a2a2D2018-12-09T033710_W.vbk, and we can store this value in a new variable:
$file = Get-VBRDeletedDehydratedBackupFile -Name vm-727.a2a2D2018-12-09T033710_W.vbk
After the files have been set as a variable, another command is used to rehydrate the file inside the local storage:
Rehydrate-VBRDeletedBackupFile -File $file
The command will execute a system task, that can be seen under History - System, filtering by name Cloud bin archive rehydration:
7.1: File rehydration task
The file is rehydrated locally in the Recycle Bin ready to be used.