Consideration & Limitations — Veeam Backup & Replication Platform Migration (Windows to Linux)
Article Applicability
This article is related to a new capability to migrate the configuration of a Windows-based Veeam Backup & Replication deployment to a Veeam Software Appliance. Due to the variability in how Veeam Backup & Replication can be used, configured, and deployed, and the complexity of migrating software configuration between platforms, this guide may not cover every possible limitation or consideration.
This article will be updated as more migrations occur and as customer feedback is received.
Purpose
This article documents potential limitations and considerations when performing a Veeam Backup & Replication configuration migration from a Windows-based deployment to a Linux-based (Veeam Software Appliance) deployment.
Before You Begin
Before reviewing limitations or proceeding with the migration guidance, please complete the following mandatory preparation steps.
Pilot migration projects are currently being performed in close cooperation with Technical Support, Sales Engineers, and Product Management. If you are considering migrating from a Windows-based installation to the Veeam Software Appliance (VSA) to take advantage of all supported features, complete the steps below before continuing with this article.
Preparation Steps
- Update your Windows deployment to the latest available patch level.
This ensures your current installation is ready for migration and includes the most recent fixes that may affect the migration process. - Sign in to the VSA conversion portal.
- Enable the “Receive proactive support” option in the product.
This allows Veeam to evaluate whether your backup server configuration can be migrated to VSA without issues.
Considerations and Limitations
Limitations due to Veeam Software Appliance Capabilities
- Veeam Cloud Connect deployments cannot be migrated to Veeam Software Appliance.
- Storage system snapshot integration support may differ between Windows-based Veeam Backup & Replication deployments and Veeam Software Appliance (Linux-based) deployments. Customers considering migration are encouraged to review the User Guide and be aware that integration with their storage system may be affected.
Note: For HPE Alletra 5000, 6000, Nimble, some versions of Nimble OS may not be supported when the Veeam Software Appliance operates in FIPS-compliant mode. - Any configuration associated with the Veeam Plug-in for Google Cloud will not be migrated because the Veeam Plug-in for Google Cloud is only available for Microsoft Windows-based backup servers.
Pre-Migration Considerations
- If the Windows-based Veeam Backup & Replication deployment, whose database is hosted on Microsoft SQL, was at any time in the past upgraded from a version older than v12, and there are still job history sessions in the database from prior to that upgrade, the migration to Veeam Software Appliance will fail. If this occurs, the solution is to reduce the session history retention to a number of weeks that is less than the last pre-v12 historical job session entry (the day the machine was upgraded to v12).
- Make sure all machines managed by the current Veeam Backup & Replication deployment on Windows are accessible by the Veeam Software Appliance (consider: networks, firewalls, and DNS). This is important because the existing deployment and the new Veeam Software Appliance might be on separate networks or domains, so after migration, you need to confirm that the Veeam Software Appliance can connect to the current infrastructure.
- If the original Veeam Backup & Replication server was used as the source for a file-to-tape job, the original backup server's short hostname must be used when selecting the Source server during migration. That short hostname must be resolvable from the Veeam Software Appliance.
- During the migration to Veeam Software Appliance, Entra ID Tenant Backup jobs are migrated, but the primary backup data associated with those jobs is not migrated and remains on the original PostgreSQL instance. There are three options for ensuring backup continuity, listed below from least to most complicated:
- [Easy] Prior to migration, configure the original Entra ID Tenant Backup jobs to use a secondary destination. After the migration, use the secondary backup data to restore it to the new PostgreSQL instance used by the Veeam Software Appliance to store Entra ID Tenant backups. Then use the map function within the Entra ID Tenant Backup job to connect the job to the restored backup data.
- [Advanced] If the migration has already been completed and the jobs did not have a secondary destination configured, it is possible to configure the Veeam Software Appliance's Entra ID Tenant Backup Repository to use the original PostgreSQL Instance. Then, use the map function within the Entra ID Tenant Backup jobs to reconnect the job to the backup data. This solution requires keeping the machine that hosts the original PostgreSQL instance available to capture Entra ID Tenant backups.
- [Expert] If the migration has already been completed, the jobs did not have a secondary destination configured to restore, and you do not wish to keep the machine hosting the original (pre-migration) PostgreSQL instance storing the Entra ID Tenant backups in service, the database storing the Entra ID Tenant backups must be migrated manually. Use 'pg_dump' to export the existing database from the original PostgreSQL instance, move that database dump to the Veeam Software Appliance, access the root shell of the Veeam Software Appliance via the Terminal UI, and use 'pg_restore' to restore the database to the local PostgreSQL instance. Then, use the map function within the Entra ID Tenant Backup jobs to reconnect the job to the backup data.
- Configuration information for CDP jobs will not be migrated and must be reconfigured manually after the migration is complete.
Agent Management Related
- Before migration, all Veeam Agent Backup Policies that are disabled must have their configurations applied successfully. Additionally, machines included in these backup policies and part of a Protection Group for Computers with Pre-installed Backup Agents need to be synced with Veeam Backup & Replication after the policy is disabled. This ensures that the agents recognize the policy as disabled. If these steps are not completed, the migration will fail.
Storage Management Related
- Before migration, if a Hitachi storage has been added as a Storage system, ensure that the timezone set within the Veeam Software Appliance settings matches the timezone used by the Windows machine where Veeam Backup & Replication was installed. This will ensure important data created by the old Veeam Backup & Replication deployed associated with the Storage Snapshots is not lost. Due to a Hitachi Plugin limitation, the timezone of the machine hosting the Veeam Backup & Replication deployment, whether Windows-based or Veeam Software Appliance, must match the time zone of Hitachi storage.
Post Migration Limitations and Considerations
- If Four-Eyes Authorization is enabled before the migration, it will be disabled during the migration and may be re-enabled by the user after the migration is complete.
- After the migration, the old Windows-based Veeam Backup Server will be added to the Veeam Software Appliance as a managed server.
Veeam recommends that, as soon as you can, migrate all roles from the old machine that hosted Veeam Backup & Replication to other machines managed by the Veeam Software Appliance, and then remove that machine from the Veeam Software Appliance configuration.
- If the source Windows-based Veeam Backup & Replication server was added as a proxy to itself, those entries will be migrated and appear as disabled proxy entries in the Veeam Software Appliance configuration.
- Any repositories that were associated with paths local to the old backup server will be migrated and continue to be accessible.
- Those repositories that were local to the old backup server that also served as extents for a Scale-Out Backup repository will automatically be placed in Maintenance mode and must be manually removed from Maintenance mode by the user.
- If the "Default Backup Repository" still existed on the old backup server, after migration, it will be renamed to "Migrated Backup Repository" to eliminate the name conflict with the Veeam Software Appliance's own Default Backup Repository.
- The Veeam Software Appliance exclusively uses Kerberos for handling domain credentials. As such, all domain usernames must be formatted in UPN format (user@fqdn). This applies to user accounts specified in Users and Roles and the Credentials Manager.
Note: The Veeam Software Appliance does not support trusted domain authentication. - Files that were used by Veeam Backup & Replication and stored on the old server must be manually copied to the Veeam Software Appliance by the user, and the settings must be updated after migration to use those files from their new location.
Tip: Use the Files view in the Veeam Backup & Replication Console to create a folder on the VSA under [Linux > This server], then use the copy-and-paste functions in the Files view to place the files in that folder.
Impacted items:- CSV files used by CSV-based Protection Groups.
Use the following command on the original Veeam Backup & Replication server to identify CSV-based Protection Groups:Get-VBRProtectionGroup -ContainerType CSV
- Scripts used by Jobs:
- CSV files used by CSV-based Protection Groups.
- After migrating to Veeam Software Appliance, any SureBackup Jobs or Application Groups that were configured to use the SQL Server Checker Script will fail during the "Running test scripts" step. These fail because the Microsoft SQL Server Checker Script requires a Windows-based Veeam Backup & Replication deployment. To resolve this, modify those SureBackup Jobs and Application Groups to remove the SQL Server test.
- If the Veeam Backup & Replication server was added to Veeam Backup Enterprise Manager, and that same Veeam Backup Enterprise Manager server will manage the Veeam Software Appliance after the migration, then the entry for the old Veeam Backup & Replication server should be updated with the new hostname/FQDN/IP using the 'Edit' option (not deleting and adding the VSA as a new server).
- If the original Windows-based Veeam Backup & Replication server was:
- Added to Veeam ONE:
After the migration, the Veeam Software Appliance must be added as a new backup server, and the entry for the old one must be deleted. Historical data in Veeam ONE for the old backup server will be lost. - Added to Veeam Recovery Orchestrator:
After migration, the Veeam Software Appliance must be added to Veeam Recovery Orchestrator as a new backup server, and the entry for the old backup server must be removed (some configurations may be lost). - Added to Veeam Service Provider Console as a hosted deployment:
After migration, the old backup server must be removed from the Veeam Service Provider Console, and then the new Veeam Software Appliance must be added. Reassign resources (e.g., tags, repositories, and VCD organizations), and then reassign jobs.
- Added to Veeam ONE:
- If a remote Linux mount server was used before the migration, after the migration, the entry for that Linux server must be edited, and then click Finish to force the credentials to be updated.
- If a repository did not have a Linux mount server specified in its settings before the migration, that setting will be updated during the migration to select the machine that is assigned as the default Linux Mount server.
- If backups are being sent to a Veeam Cloud Connect Repository, a default Windows mount server must be assigned to restore from them using certain Veeam Explorers (Veeam Explorer for Microsoft SQL Server, Veeam Explorer for Oracle, Veeam Explorer for Microsoft SharePoint, and Veeam Explorer for Microsoft Active Directory).
- If inline malware scanning is enabled, the first run of backup jobs after the migration may take longer than expected, as a full disk read operation is performed to create a RIDX file. The job session will run longer than usual, but the size of the incremental backup file will not be affected. This is necessary because the malware indexes from the Windows-based backup server are not migrated.
- During migration, jobs that were created by a user with a custom role will have their ownership reassigned to the primary backup admin. The user who created the jobs can still start and modify them, but will no longer be able to delete the jobs or restore points created by those jobs. New jobs created after the migration by those users with custom roles will not be impacted.
- After the migration, it may take up to 24 hours for the internal list of unsupported Azure Archive regions to be updated. During this time, avoid creating or modifying Azure Archive repositories, as this may result in errors.
Agent Management Related Post Migration Limitations and Considerations
- After migrating to the Veeam Software Appliance, all Protection Groups must be rescanned to update the Backup Server certificate expected by the Agents.
- After migration, all agents managed Protection Groups for Computers with Pre-installed Backup Agents must be reconfigured with a new configuration file from the Veeam Software Appliance.
- Managed agents and standalone agents that have backup jobs targeting a VBR repository, and whose operating systems are not compatible with v13 agents, will be unable to connect to the Veeam Software Appliance. This applies even if those agents are not using v13.
- After the migration is complete, all Veeam Agent Backup Policies whose destination was the Veeam Backup & Replication server must be updated to specify the DNS name or IP address of the new backup server in the policy settings.
- On the remote Distribution Server specified in the Protection Group's settings, the Veeam Distribution Service must be restarted to ensure it properly communicates with the Veeam Software Appliance.
- For Protection Groups for Microsoft Active Directory Objects that use port 636 (encrypted LDAP), open the Protection Group settings and, on the Active Directory tab, click "Change," then press "Ok" to have the software pull the domain Root CA certificate and add it to the trusted certificates.
Note: The default for Protection Group for Microsoft Active Directory Objects is to use port 389, but the option to use port 636 is available if manually entered. As documented in the user guide, "If you want to use port 636, make sure that the domain Root CA certificate is properly published in the domain."
Storage System Related
- After migration, if an IBM Flash System has been added as a Storage System, version 2.3.80 or higher of the IBM FlashSystem Plug-In for Veeam Backup & Replication must be installed manually to ensure the Veeam Software Appliance can communicate with it.
- Any Storage Snapshot-Only job that was configured to use the "Default Backup Repository" to store database log backup files will still appear to be targeting that repository, even though it was renamed. Such jobs must be updated to target a new repository, or the renamed "Migrated Local Backup Repository."
- Since the NAS filer role for NetApp ONTAP storage is the only role supported by Veeam Storage Appliance, only storage configured with this role can be migrated.
- After migration, if a Hitachi storage has been added as a Storage System, version 2.2.271 or higher of the Hitachi Plug-In for Veeam Backup & Replication must be installed manually to ensure the Veeam Software Appliance can communicate with it.
Enterprise Database Plug-ins Related
The considerations in this section for the Enterprise Database Plug-in are relevant only in the highly uncommon situation where those plug-ins were configured to store backups in the "Default Backup Repository."
- Standalone database plug‑ins (RMAN, HANA, SQL, DB2, SAP Oracle) that were configured to use the Default Backup Repository require reconfiguration after migration because the "Default Backup Repository" will have been renamed to "Migrated Backup Repository." This repository name change will cause the existing database plug-ins to become disconnected from their backup data.
(Note: Database plug-ins targeting all other repositories require no additional reconfiguration.)- To continue using the backups stored in that repository, you must reconfigure the affected plug‑in jobs to target the Migrated Backup Repository:
- Reconfigure the plug-in to use the renamed repository, Migrated Backup Repository, as the new target.
- Remove from configuration all plug-in backups that are associated with the renamed repository, Migrated Backup Repository.
- Delete all plug-in jobs that previously targeted the Default Backup Repository.
- Rescan the Migrated Backup Repository to ensure all migrated backups are recognized.
- Map all plug-ins to the Migrated Repository.
- Verify that all jobs can continue using old backups, but note that new jobs will be created (with new job names).
- If instead you want to use the Default Backup Repository of the Veeam Software Appliance:
- Reconfigure the plug-ins to target the new repository.
- Create new jobs (which will create new backups).
- If you opt to reconfigure the plug-ins to target the new Default Backup Repository, restore will still be possible from the old backup data stored in the "Migrated Backup Repository."
- To perform RMAN plug-in restores from old, now disconnected, restore points on "Migrated Backup Repository":
- Obtain the original backup ID using this command:
OracleRMANConfigTool --get-backup-for-restore
- Then, pass that backup ID to the SEND command.
- Obtain the original backup ID using this command:
- To perform RMAN plug-in restores from old, now disconnected, restore points on "Migrated Backup Repository":
- To continue using the backups stored in that repository, you must reconfigure the affected plug‑in jobs to target the Migrated Backup Repository:
If this KB article did not resolve your issue or you need further assistance with Veeam software, please create a Veeam Support Case.
To submit feedback regarding this article, please click this link: Send Article Feedback
To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.
Spelling error in text
Thank you!
Your feedback has been received and will be reviewed.
KB Feedback/Suggestion
This form is only for KB Feedback/Suggestions, if you need help with the software open a support case
Thank you!
Your feedback has been received and will be reviewed.
Oops! Something went wrong.
Please, try again later.