Case #07027430
I feel like I'm going in circles. I understand that adding more storage to anything makes everyone's life easier, but I'm struggling to understand why there isn't a better way to handle regaining NAS backup storage space within Veeam. Context: We have a File Server job with 11 shares/servers in it.
First problem I have is that when the backup job was created years ago, it was running more times that it should -- 4 times a day. As a result it was quickly consuming space. We switched this to once a day later on, but by this time the backup was taking up a large amount of space. I was trying to see if "Remove-VBRNASBackup -RestorePoint" could allow for manually removing old restore points for these file servers, but tech support helped me understand that this is not how it was designed and will break the backup chain. Because NAS backups are forward incremental forever I cannot remove any prior restore points in the chain.
Second problem is that two file servers no longer exist in the infrastructure. The VMs were decommissioned months ago. The file shares no longer exist. We do not need their backups anymore. Their data has already been dealt with externally. So I would like to delete their backups in Veeam. But it appears I cannot do anything about it. I can see the servers in Backups -> Disk -> File Share job. However, since the servers no longer exist in inventory, they don't have a NASServerId. It's been zeroed out in Veeam.
If I use Example #4 referenced in https://helpcenter.veeam.com/docs/backu ... ml?ver=120, it errors out:
If I run "Get-VBRNASServer" by itself with no switches, these two servers are not listed. I understand that it's looking for an NASServer object, but it no longer exists. I get that. But is that it? No server, so the data is stuck in the backups with no recourse?
I can see the restore points. I can get the restore point IDs using the following command. But I can't get the information in any useful state for Veeam to take action on.
A few lines from the csv file. There are thousands of restore point IDs between these two servers that I need to remove.
Now I'm stuck. I've got backups I no longer need that I seemingly cannot get rid of and I'm just looking for guidance.
I feel like I'm going in circles. I understand that adding more storage to anything makes everyone's life easier, but I'm struggling to understand why there isn't a better way to handle regaining NAS backup storage space within Veeam. Context: We have a File Server job with 11 shares/servers in it.
First problem I have is that when the backup job was created years ago, it was running more times that it should -- 4 times a day. As a result it was quickly consuming space. We switched this to once a day later on, but by this time the backup was taking up a large amount of space. I was trying to see if "Remove-VBRNASBackup -RestorePoint" could allow for manually removing old restore points for these file servers, but tech support helped me understand that this is not how it was designed and will break the backup chain. Because NAS backups are forward incremental forever I cannot remove any prior restore points in the chain.
Second problem is that two file servers no longer exist in the infrastructure. The VMs were decommissioned months ago. The file shares no longer exist. We do not need their backups anymore. Their data has already been dealt with externally. So I would like to delete their backups in Veeam. But it appears I cannot do anything about it. I can see the servers in Backups -> Disk -> File Share job. However, since the servers no longer exist in inventory, they don't have a NASServerId. It's been zeroed out in Veeam.
Code:
PS> $backupfile = Get-VBRNASBackup -Name "FileServers"PS> Get-VBRNASServer -Backup $backupfileType : FileServerServer : 58c4f609-d377-4a16-a273-2eb5c60b0d53Name : server1.example.comId : 00000000-0000-0000-0000-000000000000CacheRepository :BackupIOControlLevel : MediumType : FileServerServer : b95931b4-b303-42b5-8199-679239a80c2aName : server2.example.comId : 00000000-0000-0000-0000-000000000000CacheRepository :BackupIOControlLevel : MediumCode:
PS> $backupfile = Get-VBRNASBackup -Name "FileServers"PS> $server = Get-VBRNASServer -Name "server1.example.com"PS> Get-VBRNASBackupRestorePoint -NASServer $server -NASBackup $backupfileGet-VBRNASBackupRestorePoint : Cannot validate argument on parameter 'NASServer'. The argument is null or empty.Provide an argument that is not null or empty, and then try the command again.At line:1 char:41+ Get-VBRNASBackupRestorePoint -NASServer $server -NASBackup $backupfil ...+ ~~~~~~~ + CategoryInfo : InvalidData: (:) [Get-VBRNASBackupRestorePoint], ParameterBindingValidationException + FullyQualifiedErrorId : ParameterArgumentValidationError,Veeam.Backup.PowerShell.Cmdlets.GetVBRNASBackupRestorePointI can see the restore points. I can get the restore point IDs using the following command. But I can't get the information in any useful state for Veeam to take action on.
Code:
PS> Get-VBRNASBackupRestorePoint -NASBackup $backupfile | Export-CSV -NoTypeInformation VBRNASBackupRestorePoint-ALL.csvCode:
IdNASServerIdNASServerNameBackupIdCreationTimeTypeIsComplete45932d0b-a2bd-4216-a1f0-019a3130258600000000-0000-0000-0000-000000000000server1.example.com21ff000d-c89b-46cd-98a5-6aefac2bb6eb11/30/2021 00:00FullTRUE2b337729-4fa4-4c0d-93f2-028557536eeb00000000-0000-0000-0000-000000000000server1.example.com21ff000d-c89b-46cd-98a5-6aefac2bb6eb12/16/2021 00:00FullTRUE005d44a8-42f1-405b-b00e-02953452974a00000000-0000-0000-0000-000000000000server1.example.com21ff000d-c89b-46cd-98a5-6aefac2bb6eb11/28/2021 00:00FullTRUEabdb781c-df4d-4963-bb2c-02caaa97b7a000000000-0000-0000-0000-000000000000server1.example.com21ff000d-c89b-46cd-98a5-6aefac2bb6eb12/11/2021 00:00FullTRUEdf98c194-c018-4bf7-ad88-034955a945aa00000000-0000-0000-0000-000000000000server1.example.com21ff000d-c89b-46cd-98a5-6aefac2bb6eb12/07/2021 18:00FullTRUEfeac9be2-f601-4c05-8765-037fb097156100000000-0000-0000-0000-000000000000server1.example.com21ff000d-c89b-46cd-98a5-6aefac2bb6eb12/27/2021 12:00FullTRUEStatistics: Posted by rwatt — Nov 30, 2023 11:31 pm
