Linux: Reverting from Version 7.1 to the previous V6 server

If you must revert to the previous version of the server after an upgrade, you must have a full database backup from your original version. You must also have the server installation media for your original version and key configuration files. Carefully follow the preparation steps before you upgrade the server. By doing so, it might be possible to revert to the previous version of the Tivoli® Storage Manager server with minimal loss of data.

Before you begin

You must have the following items from the earlier version of the server:

Server database backup
Volume history file
Device configuration file
Server options file

About this task

Use the same instructions whether you are reverting within releases or to an earlier release, for example, from 6.2.2 to 6.2.0 or from 6.2.2 to 6.1.2. The older version must match the version that you used before the upgrade to 7.1.3.

Attention: Specify the REUSEDELAY parameter to help prevent backup-archive client data loss when you revert the server to a previous version.

Steps for reverting to the previous server version

About this task

Complete the following steps on the system that has the V7.1 server.

Procedure

Halt the server to shut down all server operations by using the HALT command.
Remove the database from the database manager, then delete the database and recovery log directories.
1. Manually remove the database. One way to remove it is by issuing this command:
```
dsmserv removedb tsmdb1
```
2. If you must reuse the space that is occupied by the database and recovery log directories, you can now delete these directories.
Use the uninstallation program to uninstall the V7.1.3 server. Uninstallation removes the server and the database manager, with their directories. For details, see Linux: Uninstalling Tivoli Storage Manager.
Reinstall the version of the server program that you were using before the upgrade to V7.1. This version must match the version that your server was running when you created the database backup that you restore in a later step. For example, the server was at version 6.2.2.0 before the upgrade, and you intend to use the database backup that was in use on this server. You must install the 6.2.2.0 fix pack to be able to restore the database backup.
Copy the following files to the instance directory.
- Device configuration file
- Volume history file
- The server options file (typically dsmserv.opt)
Configure the new server database by using the configuration wizard. To start the wizard, issue the following command:
```
. /dsmicfgx
```
Ensure that no servers are running in the background.
Restore the database to a point in time before the upgrade.
If you enabled data deduplication for any FILE-type storage pools that existed before the upgrade, or if you moved data that existed before the upgrade into new storage pools while using the V7.1 server, you must complete additional recovery steps. For more details, see Additional recovery steps if you created new storage pools or enabled data deduplication.
If the REUSEDELAY parameter setting on storage pools is less than the age of the database that you restored, restore volumes on any sequential-access storage pools that were reclaimed after that database backup. Use the RESTORE VOLUME command.
If you do not have a backup of a storage pool, audit the reclaimed volumes by using the AUDIT VOLUME command, with the FIX=YES parameter to resolve inconsistencies. For example:
```
audit volume volume_name fix=yes
```
If client backup or archive operations were completed using the V7.1 server, audit the storage pool volumes on which the data was stored.

Additional recovery steps if you created new storage pools or enabled data deduplication

If you created new storage pools, turned on data deduplication for any FILE-type storage pools, or did both while your server was running as a V7.1.3 server, you must complete more steps to return to the previous server version.

Before you begin

To complete this task, you must have a complete backup of the storage pool that was created before the upgrade to V7.1.3.

About this task

Use this information if you did either or both of the following actions while your server was running as a V7.1.3 server:

You enabled the data deduplication function for any storage pools that existed before the upgrade to V7.1.3 program. Data deduplication applies only to storage pools that use a FILE device type.
You created new primary storage pools after the upgrade and moved data that was stored in other storage pools into the new storage pools.

Complete these steps after the server is again restored to V6.

Procedure

For each storage pool for which you enabled the data deduplication function, restore the entire storage pool by using the RESTORE STGPOOL command.
For storage pools that you created after the upgrade, determine what action to take. Data that was moved from existing V6 storage pools into the new storage pools might be lost because the new storage pools no longer exist in your restored V6 server. Possible recovery depends on the type of storage pool:
- If data was moved from V6 DISK-type storage pools into a new storage pool, space that was occupied by the data that was moved was probably reused. Therefore, you must restore the original V6 storage pools by using the storage pool backups that were created before the upgrade to V7.1.
  If no data was moved from V6 DISK-type storage pools into a new storage pool, then audit the storage pool volumes in these DISK-type storage pools.
- If data was moved from V6 sequential-access storage pools into a new storage pool, that data might still exist and be usable in storage pool volumes on the restored V6 server. The data might be usable if the REUSEDELAY parameter for the storage pool was set to a value that prevented reclamation while the server was running as a V7.1.3 server. If any volumes were reclaimed while the server was running as a V7.1.3 server, restore those volumes from storage pool backups that were created before the upgrade to V7.1.3.