Quantcast
Channel: Veeam Support Knowledge Base
Viewing all articles
Browse latest Browse all 4362

How to Migrate Veeam Backup for Salesforce off CentOS

$
0
0

How to Migrate Veeam Backup for Salesforce off CentOS

KB ID: 4664
Product: Veeam Backup for Salesforce | 3.0
Published: 2024-09-18
Last Modified: 2024-09-18

Purpose

This article documents how to migrate a Veeam Backup for Salesforce (VBSF) deployment from a machine running CentOS 7 to a machine running a supported Linux distro.

Starting in Veeam Backup for Salesforce version 3, CentOS will no longer be supported as a distro for the deployment of Veeam Backup for Salesforce.

Solution

This procedure will guide you through migrating to a new VBSF version 3 deployment on a new server with a supported Linux distro and configuring that new deployment to reuse the product configuration and backup databases from the old deployment.

 

Before making any changes to the environment, please create a VM-level or disk-level snapshot to ensure you can roll back changes should something go wrong.

Part 1: Prepare the Source Server for Migration

  1. Disable all backup policies.
  2. Ensure that there are no active backup policies or restore jobs.
  3. Stop the backend service:
sudo systemctl stop vbsf-backend

Part 2: Deploy Veeam Backup for Salesforce on New Server

  1. Begin installing VBSF on the target server, but do not open the generated URL of the initial setup wizard.
  2. Stop backend service of target server:
sudo systemctl stop vbsf-backend

Part 3: Migrate Data From the Source Server to the Target Server

  1. If the source server was running VBSF v2, copy the product encryption key from the source server to the target server and overwrite the existing key file.
    Note: The file location and name format are different. You must rename the VBSF v2 key to match the v3 key name and then overwrite the v3 key on the target server with the now renamed v2 key from the source server.
    • VBSF 2.0 location and naming format:
      /opt/vbsf/vbsf-backend.product.key
      
    • VBSF 3.0 location and naming format:
      /opt/vbsf/vbsf-backend/config/product.key
      
    As an example, the key can be migrated using scp from the source server, as shown in the examples below:
sudo scp /opt/vbsf/vbsf-backend.product.key root@10.10.46.64:/opt/vbsf/vbsf-backend/config/product.key
  1. After copying the key from the source server to the target server, run the following commands on the target server to configure file ownership and set the required access for the product key:
sudo chown vbsf:vbsf /opt/vbsf/vbsf-backend/config/product.key
sudo chmod 600 /opt/vbsf/vbsf-backend/config/product.key
  1. Delete https.properties from target server:
sudo rm /opt/vbsf/vbsf-backend/config/https.properties
  1. From the source server, move the contents of the data folder (containing the backed-up files and metadata) to the target server.
    Below are the equivalent folder paths for the past versions:
    • VBSF v1
      /opt/vbsf/vbsf-backup/data/
      
    • VBSF v2
      /opt/vbsf/data/
      
    • VBSF v3
      /opt/vbsf/data/
      
Example Methods to Migrate Data

You can use rsync to copy folders with the following options:

  • -a: archive mode
  • -p: preserve attributes
  • -P: show progress and allow the resumption of partial transfers
  • -q: quiet mode
  • -z: compress files during transfer

If the amount of data is large, you could consider using a cron to overcome timeouts. Using this command you will be prompted to provide the root password for the target server.

Note: This example is based on migrating from a source server using VBSF v2 to a target server running v3. If your source machine is running v1, update the path accordingly.

sudo rsync -apPqz /opt/vbsf/data root@10.10.46.64:/opt/vbsf/data/
Alternatively, if the data size is small, you can simply use scp:
sudo scp -r /opt/vbsf/data root@10.10.46.64:/opt/vbsf/data/
  1. After copying the data folder contents to the target server, run the following command on the target server to configure file ownership and set the required access level for backed-up data:
sudo chown -R vbsf:vbsf /opt/vbsf
sudo chmod -R 755 /opt/vbsf
  1. It is important to connect the existing configuration database to the new installation. Otherwise, you must create backup policies and do a full initial backup for each protected organization. If configuration or backup databases are located on the management server of the source server, you might want to consider exporting those databases to a new location.

    For more information, review:

Part 4: Finalize Migration

  1. Start the backend service on the target VBSF server.
sudo systemctl start vbsf-backend
  1. Update the Salesforce Connected App with the Callback URL of the target installation to allow the installation to connect to Salesforce.
  2. If the PostgreSQL instance is running version 12, you must upgrade it first to a supported version before proceeding.
    For more information, review Veeam KB4665.
  3. Proceed with the initial setup wizard using the URL generated during installation.
    • When connecting to PostgreSQL, make sure to provide the connection details of the migrated configuration databases.
    • Select the “Customize” option to provide the configuration database name.
    • Select “Skip backup policy creation” to configure the connection to backup databases later.
  4. Update the migrated configuration of the product with the address of the new management server.
    Log in with the local administrator account, go to Configuration > About > Advanced Settings, and edit the backend.domain parameter to match the domain name of the target installation.
  5. If the databases were located on the management server and were migrated with the configuration database, you must update the connection details for each backup database under Configuration > Salesforce > Databases.
  6. Enable backup policies
    • Once upgraded, the first run of backup policies will start database migration procedures. These procedures will block any changes to the backup database, and backup policies may report a Failed status.

      Note:
       Do not restart the application/appliance during the database migration, as doing so will result in a corrupted installation and backup repository.
    • Once migration is finished, backup policies will start working normally.
  7. If Single Sign-On with Microsoft Entra ID was configured, the configuration change is required on the Microsoft Entra ID side:
    • In Microsoft Entra ID, go to the App Registration > Authentication section and modify the Redirect URI to match the domain name of the management server.
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.

Viewing all articles
Browse latest Browse all 4362

Trending Articles