Migrating onboard vSnap data to a stand-alone vSnap server

Beginning with IBM Spectrum® Protect Plus Version 10.1.7, the onboard vSnap server is no longer included. If you upgrade your system to IBM Spectrum Protect Plus V10.1.7, but data remains in an onboard vSnap server from a previous release, you must migrate the data to a new, stand-alone vSnap server.

Before you begin

Beginning with IBM Spectrum Protect Plus V10.1.7, new deployments will no longer contain an onboard vSnap server. Systems upgraded from a previous version of IBM Spectrum Protect Plus still contain an onboard vSnap server which can be part of the Demo site. The onboard vSnap server will no longer be upgraded as part of general updates to IBM Spectrum Protect Plus.

The LocalvSnapAdmin identity was used as the identity to connect to the onboard vSnap server. In some cases, this identity may have been used to access other vSnap servers. If the identity was used to connect to other vSnap servers, a new identity for those servers must be created. Use the serveradmin account to connect to vSnap servers.

Do not unregister the onboard vSnap server from IBM Spectrum Protect Plus until prompted.

Ensure that sufficient space is available on the datastore for a stand-alone vSnap server deployment.

Do not explicitly initialize the new vSnap server that will be deployed as part of this procedure. Instead, the configuration of the onboard vSnap server will be copied to the new vSnap server.

Attention: Follow the procedure carefully. If not followed, this procedure can result in a loss of data.

About this task

In previous releases, an onboard vSnap server was included for proof-of-concept (POC) and demo purposes. The vSnap server was named localhost and was part of the Primary site by default. Beginning with IBM Spectrum Protect Plus V10.1.5, the onboard vSnap server was part of a Demo site that provided limited functionality. Users were able to manually remove the onboard vSnap from the Demo site and then register it with another site at which point the vSnap server was no longer limited in functionality.

Determine whether an onboard vSnap server was used in the previous release. Users who did not unregister the onboard vSnap from the Demo site will follow a different procedure from users who unregistered the onboard vSnap server from the Demo site and assigned the server to another site. Consider the two scenarios below:

Scenario 1: If the onboard vSnap was unused or previously used only in the Demo site, stop using the onboard vSnap. Unregister the vSnap from IBM Spectrum Protect Plus, for more information, see Unregistering a vSnap server. After completing those steps, uninstall the vSnap software from the IBM Spectrum Protect Plus server. Skip the steps and begin with Step 9 in this procedure.

Scenario 2: If the onboard vSnap was unregistered from the Demo site and used in production under another site, do not unregister the onboard vSnap server from IBM Spectrum Protect Plus. The procedure in this topic will reference other topics. It may be helpful to have these topics open when:

Manually upgrade the onboard vSnap server to version 10.1.7 using the .run file. Follow to the general procedure for upgrading an external vSnap server. For more information, see Updating a vSnap server.
Deploy a new stand-alone vSnap server using the version 10.1.7 OVA. For more information, see Installing a virtual vSnap server in a VMware environment.
Upon completing the migration of data, uninstall the vSnap software from the IBM Spectrum Protect Plus server. These steps are detailed in this procedure beginning with Step 9.

Procedure

Update the onboard vSnap server and collect the vSnap pool information.
1. Using secure shell (SSH), log in to the onboard vSnap as the serveradmin user.
2. Upgrade the vSnap server to the most recent release. For more information, see Updating a vSnap server.
3. Determine the version level of the vSnap server. At the command prompt enter the vsnap system info command:
```
$ vsnap system info
```
4. Determine all the disks labeled vsnap_pool. The storage pool is comprised of these disks which will be detached from the onboard vSnap server and attached to the new vSnap server later in this procedure. At the command prompt, issue the vsnap disk show command to identify the disks:
```
$ vsnap disk show
```
Deploy a new, stand-alone vSnap server using the most recent .ova, apply custom settings, and verify the version level.
1. Log in to the vSphere Client.
2. Deploy a new stand-alone vSnap server using the most recent version of the vSnap .ova. For more information, see Installing a virtual vSnap server in a VMware environment.
3. The new, stand-alone vSnap server will contain an unused 100GB disk that is used as the initial disk for creating a new storage pool. Detach this disk from the stand-alone vSnap server and delete it.
4. Configure the network properties as appropriate to your environment on the newly created vSnap server. Document the IP address or hostname for later use in this procedure.
5. Using secure shell (SSH), log in to the newly created vSnap as the serveradmin user.
6. Determine the version level of the newly created vSnap server. At the command prompt enter the vsnap system info command:
```
$ vsnap system info
```
  This version should match the version level of the onboard vSnap server that was upgraded and verified in the first step. If not, upgrade one or both of the vSnap servers to the latest release to ensure that they are at the same version level.
Pause all jobs in IBM Spectrum Protect Plus, document replication partnerships, and delete the partnerships from the onboard vSnap.
1. Log on to the IBM Spectrum Protect Plus server.
2. Jobs must not be actively running or scheduled to run during the migration procedure. Pause the schedule for all jobs to ensure that they do not attempt to run while the migration is occurring. Click Jobs and Operations > Schedule and then click Pause All Jobs. Verify that no jobs are running by clicking Jobs and Operations > Running Jobs.
3. Modify the settings for the onboard vSnap server. Navigate to System Configuration > Backup Storage > Disk and click on the settings icon beside the onboard vSnap.
4. Click on the Partners tab. Document the IP address or hostname of each replication partner for later use in this procedure.
5. Click the delete icon beside each replication partner. Removing the partnerships is safe and will not affect the replication data. The partnerships will be recreated in a subsequent step after the migration is complete.
Backup the onboard vSnap server configuration, transfer the configuration file to the new stand-alone vSnap server, and stop and disable the vSnap services on the onboard vSnap server.
1. Using secure shell (SSH), log in to the onboard vSnap server as the serveradmin user.
2. Create a backup of the vSnap configuration using the vsnap system config backup command. In this example, the config backup is saved in the root of the serveradmin user’s home directory:
```
$ vsnap system config backup --outfile /home/serveradmin/vsnap_config_backup.tar.gz
```
3. Copy the vsnap_config_backup.tar.gz from the onboard vSnap server to the newly created stand-alone vSnap server into the /home/serveradmin directory. SCP can be used to copy the file. In this example, <ip_address_new_vsnap> is a variable used to denote the IP address of the newly created stand-alone vSnap server. If prompted, accept the fingerprint and enter yes to continue connecting.
```
$ scp vsnap_config_backup.tar.gz serveradmin@<ip_address_new_vsnap>:/home/serveradmin
```
4. Enter the password for the serveradmin account on the stand-alone vSnap server. The file will begin transferring.
5. Disable the vSnap services for the onboard vSnap server using the systemctl stop and systemctl disable commands:
```
$ sudo systemctl stop vsnap
```
```
$ sudo systemctl disable vsnap
```
Restore the onboard vSnap server configuration to the new stand-alone vSnap server.
1. Using secure shell (SSH), log in to the newly created vSnap as the serveradmin user.
2. Restore the config backup from the onboard vSnap server to the stand-alone vSnap server using the vsnap system config restore command:
```
$ vsnap system config restore --file /home/serveradmin/vsnap_config_backup.tar.gz
```
Power off the onboard vSnap server and the stand-alone vSnap server, detach the disks from the onboard vSnap and attach the disks to the stand-alone vSnap server. Power on both vSnap servers.
1. Log in to the vSphere Client.
2. Power off the onboard vSnap and the stand-alone vSnap virtual machines and edit the settings of the virtual machine that has the onboard vSnap.
3. Detach the disks associated with the vSnap pool that is to be migrated as identified in Step 1d.
4. Edit the settings of the stand-alone vSnap virtual machine and attach the disks that were detached from the onboard vSnap server in Step 6c.
5. Power on the onboard vSnap and the stand-alone vSnap virtual machines.
Verify the status of both the onboard vSnap server and the newly deployed stand-alone vSnap server.
1. Using secure shell (SSH), log in to the onboard vSnap server as the serveradmin user.
2. Run the vsnap_status command to determine the status of the vSnap services on the onboard vSnap server. It is expected that the services will no longer be running since the systemctl stop and systemctl disable commands were previously executed in Step 4.
```
$ vsnap_status 
```
3. Using secure shell (SSH), log in to the newly created vSnap as the serveradmin user.
4. Run the vsnap_status command to determine the status of the vSnap services on the stand-alone vSnap server. The expected outcome is that the services will start and mount the storage pool.
```
$ vsnap_status
```
  Note: It may take up to 15 minutes for all services to start. Periodically run the vsnap_status command to check the status.
5. After all vSnap services are active, execute the vsnap pool show command to verify that the storage pool is online:
```
$ vsnap pool show
```
Update the vSnap server registration, the associated credentials, re-add the replication partners, and release the job schedules.
1. Log on to the IBM Spectrum Protect Plus server.
2. Click on System Configuration > Backup Storage > Disk and click on the edit icon beside the onboard vSnap server.
3. Enter the IP address or the hostname in the Hostname/IP field of the newly created stand-alone vSnap server.
4. The existing user may display as LocalvSnapAdmin or as another identity. Deselect Use existing user. Enter serveradmin in the User ID field and the associated password for the stand-alone vSnap server in the Password field.
5. Click Save.
6. On the Disk screen locate the vSnap server that was just edited and click on the actions menu icon . Select Refresh.
7. After the refresh completes verify that the information for the vSnap server is accurate.
8. Click on settings icon and then click on the Partners tab.
9. Re-enter the replication partners that were removed in Step 3. For more information, see Configuring backup storage partners.
10. Release schedules for all jobs that were paused in Step 3. Navigate to Jobs and Operations > Schedule and then click Release All Schedules.
Remove the vSnap software from the IBM Spectrum Protect Plus server.
1. Using secure shell (SSH), log in to the IBM Spectrum Protect Plus server as the serveradmin user.
2. Execute the yum remove commands to remove the vSnap server software from the IBM Spectrum Protect Plus server:
```
$ sudo yum remove vsnap
```
```
$ sudo yum remove vsnap-dist
```

Results

The migration from the onboard vSnap to a newly created stand-alone vSnap server is complete. All jobs that used the onboard vSnap will now use the new vSnap server. All data previously backed up to the onboard vSnap can be restored from the new vSnap server. Previously scheduled backup, replication, and cloud copy jobs will continue, as data is incrementally transferred to the new vSnap server.