Veeam

General Cloud Backup, Veeam

Veeam and AWS Storage

Amazon cloud storage, particularly S3 and Glacier, are popular options for offsite data storage, and Veeam is a leading solution for VM backups. You can integrate the two, but the question is: should you? The answer depends on several factors. Veeam and AWS Integration Integrating Veeam Backup & Replication with Amazon storage is done through an AWS Storage Gateway—an appliance that connects your Veeam server to the AWS Cloud. You can configure the gateway as a file server, direct attached storage, or as a Virtual Tape Library (VTL). Virtual Tape Library (VTL) Using AWS as a virtual tape library allows you to present the storage gateway to Veeam as a tape server, which lets you create tape backups in AWS. Veeam Cloud Connect: A Simpler Option Alternatively, Veeam offers Cloud Connect, an offsite backup method built into its platform. Cloud Connect partners—third-party Veeam service providers—offer storage and compute resources specifically tailored for offsite backups. Users simply input their provider’s credentials into Veeam and can start sending backups to the Cloud Repository. For most businesses, a Cloud Connect partner offers a simpler, more cost-effective solution, allowing true incremental forever backups without the hassle of setting up your own infrastructure. When to Use AWS for Offsite Backups Using AWS for offsite backups with Veeam can work, but regular full backups are required. This option might only be suitable if: Conclusion While AWS can be used for offsite Veeam backups, it’s generally not the most efficient or cost-effective option for larger datasets or frequent backups. A Veeam Cloud Connect partner provides a better solution for: Choosing a Cloud Connect provider often leads to simpler management, lower costs, and faster backups, making it a more feasible choice for most businesses.

Veeam

VEEAM 9.5 ReFS Integration

Veeam 9.5 and ReFS: Fast Cloning and Spaceless Full Technology Veeam Backup & Replication 9.5 integrates with Windows Server 2016 ReFS, bringing two key benefits to synthetic and merge operations: Fast Cloning and Spaceless Full Backups. Both of these features rely on ReFS block cloning, which allows Veeam to quickly copy data blocks within files, or even between files, without creating duplicate copies of the data. Instead, ReFS creates pointers to existing data blocks, significantly improving performance and storage efficiency. Fast Cloning Fast Cloning with ReFS dramatically reduces the time and resources required for synthetic operations. Because new full backups only reference existing data blocks (using pointers), rather than duplicating the data, synthetic operations become much faster and less resource-intensive. Spaceless Full Backups Spaceless full backups are made possible through the use of pointers, allowing new synthetic backups to take up significantly less storage space. Since the majority of data remains unchanged between backup copies, spaceless fulls only reference existing data blocks rather than creating new copies. This reduces the storage required for full backups to a fraction of what would otherwise be needed. Storage Efficiency with ReFS While spaceless full backups offer tremendous storage savings, it’s important to note that global deduplication is not supported. ReFS spaceless full backups reduce storage usage within copies of the same full backup file, but they won’t deduplicate across multiple backup files like a deduplication appliance would. Still, the storage savings can be significant. For example, after migrating a customer with nearly 1TB of native backup size from an NTFS repository to an ReFS repository, the utilized storage dropped to less than half of the native file size after one month of weekly and monthly GFS backup copies. As older GFS restore points are removed and replaced with ReFS spaceless fulls, the storage utilization will continue to decrease. Encryption with Spaceless Fulls One major advantage of ReFS spaceless fulls is that encryption is fully supported. Unlike deduplication, which prevents encryption, spaceless fulls in ReFS allow for both encryption and storage efficiency. This means your backups can remain secure while still benefiting from the space-saving advantages of ReFS. Adding ReFS Volumes as Veeam Repositories To leverage the benefits of ReFS with Veeam, older repositories need to be attached to a Windows Server 2016 machine and formatted as ReFS. If you’ve previously added a Windows Server 2016 ReFS volume as a repository, it will need to be re-added after upgrading to Veeam v9.5 for the system to recognize the new features. Important:Veeam’s fast cloning and spaceless full technologies only support ReFS volumes created on Windows Server 2016. ReFS volumes formatted on Windows Server 2012 will not benefit from these features, as they use an older version of ReFS. Additionally, restore points created before the v9.5 upgrade won’t see the new benefits. To fully utilize fast cloning and spaceless full backups, all full and incremental backups involved in synthetic operations must be created using Veeam v9.5 with a Windows Server 2016 ReFS repository. The Fast Clone tag will appear in the job activity logs once the feature is active, indicating the synthetic operation is using the optimized ReFS technology. Veeam v9.5 was recently released and with it came a large number of improvements and added features. Namely, the seamless integration of Microsoft Server 2016’s Key Recommendations Update: Make sure to use 64K Block Size when formatting the Veeam repository volumes to avoid issues with 4K Block Size and ReFS. Read this post for more information.

Veeam

Issues Running Backups or Rescanning Repository After Veeam Upgrade

Just recently, right after upgrading to Veeam 9.5, we ran into an error with one of our customers that would show up whenever backups started to run and when we tried to rescan the Veeam repository. The errors messages were: Warning Failed to synchronize Backup Repository Details: Failed to synchronize 2 backups Failed to synchronize 2 backups Warning Failed to import backup path E:|PATH|TO|BACKUP|FILES|BackupJobName.vbm Details: Incorrect file system item link received: BackupJobName Based on the errors it looked like there were issues with the database entries for the backup job mentioned in the error. As a troubleshooting step we tried removing the backup files from the GUI under Backup & Replication>Backups by right clicking on the backup and selecting ‘Remove from Configuration.’ However, this ended up giving us the same error in a popup dialogue: Incorrect file system item link received: BackupJobName After opening a ticket with Veeam they informed us that this is a known issue caused by unexpected backup entries in the VeeamBackup SQL database. Namely, the issue backup jobs were listed in the database with a zero entry for the job ID or repository ID causing Veeam to not be able to locate the backup files. Because this involves the Veeam SQL database we are going to be making changes to the database so it’s best to back it up before the next steps. Here’s a knowledge base article from Veeam that shows the suggested methods to backing up the database. To determine whether there are any errant backup entries in the SQL database run the following query: SELECT TOP 1000 [id] ,[job_id] ,[job_name] ,[repository_id] FROM [VeeamBackup].[dbo].[Backup.Model.Backups] Under ‘repository_id’ you should see one or more of the backup jobs showing ‘00000000-0000-0000-0000-000000000000’ or ‘NULL’ as the id for job or repository. Any entries with this issue will need to be removed from the database in order to resolve the error. It’s best practice to save a backup of the SQL database before making any changes. If you’re unsure of how to back up the SQL database, follow Veeam’s knowledge base article.  After backing up the SQL database run the following query for each job with ‘00000000-0000-0000-0000-000000000000’ as the repository_id: EXEC [dbo].[Backup.Model.DeleteBackupChildEntities] ‘REPLACE_WITH_ID’ EXEC [dbo].[Backup.Model.DeleteBackup] ‘REPLACE_WITH_ID’ Replacing the ‘job_id’ with that of any backups with the unexpected ‘repository_id’ found with the previous query. After that issues with the local backup server was resolved. However, we were still seeing errors when trying to connect the backup server to our cloud connect repository to do backup copies. We were still getting the following errors: Warning Failed to synchronize Backup Repository Details: Failed to synchronize 2 backups Failed to synchronize 2 backups Warning Failed to import backup path E:|PATH|TO|BACKUP|FILES|BackupJobName.vbm Details: Incorrect file system item link received: BackupJobName In order to resolve this we had to remove the entries for the problem jobs from the cloud connect server database. For those using a cloud connect service provider you will have to have them make changes to the SQL database. We had 2 VMs that were giving the ‘Incorrect file system item link received: JobName” error. So we had to remove any entries for those jobs from the SQL db. We ran the following query to get the Job ID of both jobs mentioned in the errors: SELECT TOP 1000 [id] ,[job_id] ,[job_name] FROM [VeeamBackup].[dbo].[Backup.Model.Backups] Then we ran the same delete query as before using the new job_id’s: EXEC [dbo].[Backup.Model.DeleteBackupChildEntities] ‘REPLACE_WITH_ID’ EXEC [dbo].[Backup.Model.DeleteBackup] ‘REPLACE_WITH_ID’ After those entries were deleted we were able to rescan the repository. Lastly, once we rescanned our cloud repository and imported the existing backups we started getting the following error message: Warning Failed to import backup path E:|PATH|TO|BACKUP|FILES|BackupJobName.vbm Details: Path E:|PATH|TO|BACKUP|FILES|BackupJobName2016-11-21T220000.vib is absolute and cannot be added to other path This error indicates that there is a problem where the backup chain isn’t accurately resolving the location of the GFS restore points. In order to resolve this we had to manually remove the Imported backups from the cloud connect server by going to Backup & Replication>Backups and selecting the backup job and choosing ‘Remove from Configuration’ making sure to check ‘Include archived full backups.’ After the backups had been removed from the cloud connect repository we were able to manually rescan the repository on the local backup server and the backup files were imported again successfully. Update:  After deleting these affected rows using the commands above you may get the following error message: Unable to map tenant cache ID ‘ID-GOES-HERE’ to service provider side ID ‘ID-GOES-HERE’ because it is already mapped to ID ‘ID-GOES-HERE’ If you do see this error a solution can be found in this Veeam KB article. Essentially, the data for these deleted rows still exists in the Veeam DB cache table and needs to be removed. In order to do this run the following query on the VeeamBackup database: delete from [cachedobjectsidmapping] This will delete the DB cache table. In order to re-populate it you will need to rescan the service provider and the Cloud Repository.

Scroll to Top