Migrating Backup Server and Replication Server from version 2.5.5 to 3.2

You can install Gbackup v3.2 Server Build on top of Gbackup v2.5.5 installations in Backup and Replication Servers. Gbackup will automatically migrate to v3.2. Before migrating to v3.2, please make a note of the following instructions:

• To upgrade Backup Server to Gbackup v3.2, you should be currently running Gbackup v2.5.5 in the Backup Server.

• To upgrade Replication Server to Gbackup v3.2, you should be currently running Gbackup v2.5.5 in the Replication Server.

• To upgrade Backup/Replication Server to v3.2, just install Gbackup v3.2 server build on top of the Gbackup v2.5.5 installation. DO NOT UNINSTALL v2.5.5..

• If you are currently running a Gbackup version older than v2.5.5 in the Backup/Replication Server, make sure, you first upgrade to them v2.5.5. After upgrading to v2.5.5, make sure you start Gbackup to complete the migration process. Also, make sure you log into the web console and make sure the upgrade to v2.5.5 has completed successfully before installing v3.2 on top of v2.5.5.

If you are running Gbackup v2.5.1 in the Backup/Replication Servers, then please follow the migration steps given in "Migrating from version 2.5.1 to 2.5.5" section below.

NOTE: After migrating the Backup Server to v3.2 version, the existing v2.5.1 clients can continue the incremental backup to v3.2 Backup Server.

Migrating Client from version 2.5.1 to 3.2

You can install Gbackup v3.2 Client Build on top of the existing Client v2.5.1 installation and Gbackup will automatically migrate it to v3.2. Before migrating to v3.2, please make a note of the following instructions:

• To upgrade a Client to v3.2, you should be currently running v2.5.1.

• To upgrade a Client to v3.2, just install v3.2 on top of the v2.5.1 installation. DO NOT UNINSTALL v2.5.1.

• If you are currently running a Gbackup Client version older than v2.5.1, make sure you first upgrade the Client to v2.5.1 and then start Gbackup to complete the migration process before installing v3.2.

Before upgrading Clients to v3.2, you must ensure that your Backup Server has been upgraded to v3.2. The existing v2.5.1 client can continue backing up to a v3.2 Backup Server.

Client machines running Gbackup version older than v2.5.1 cannot be migrated directly to v3.2. If you are running Gbackup v2.4 in the client machines, then follow the migration steps given in "Migrating from version 2.4 to 2.5.1" section below.

Migrating from version 2.5.1 Client-Server to 3.2

From Gbackup v2.5.5, Client-Server mode of deployment is not supported. Hence to migrate v2.5.1 Client-Server installations to v3.2, Gbackup mode should be first changed to either Client Only or Server Only before migration.

Steps to migrate v2.5.1 Client-Server to v3.2 Client-Only:

• Stop Gbackup.

• Set the StartModule attribute to 602(Client-Only) in the <InstallationLocation>/conf/SGConfiguration.conf file.

• Start Gbackup.

• Now, install SG v3.2 Client Build on top of the existing v2.5.1 Client-Only installation.

Steps to migrate v2.5.1 Client-Server to v3.2 Server-Only:

• Stop Gbackup.

• Set the StartModule attribute to 601(Server-only) in the <InstallationLocation>/conf/SGConfiguration.conf file.

• Start Gbackup.

• Now, install SG v2.5.5 Server Build on top of the existing 2.5.1 Server-Only installation.

  Please note that migration to v2.5.5 takes some time. Once v2.5.5 migration is complete, you can login to Gbackup web console and make sure the data is successfully migrated to v2.5.5.

• Now, install SG v3.2 Server Build on top of the existing v2.5.5 Server installation.

NOTE: Migrating from versions 3.0 or 3.1 to 3.2 is not supported.

Migrating from version 3.0 to 3.1

You can install Gbackup v3.1 on top of the existing version 3.0 and Gbackup will automatically migrate to v3.1. Before migrating to v3.1, please make a note of the following instructions:

• To upgrade to v3.1, you should be currently running the v3.0.

• To upgrade to v3.1, just install v3.1 on top of the v3.0 installation. DO NOT UNINSTALL v3.0.

• If you are currently running Gbackup version older than v3.0, migration to v3.1 is currently not supported.

Also ensure that your Backup Server is first upgraded from v3.0 to v3.1 before upgrading the v3.0 clients. Only v3.0 and v3.1 Gbackup clients can backup to v3.1 Gbackup Backup Server, Therefore, before upgrading clients to v3.1, you must ensure that your Backup Server has been upgraded to v3.1. We have ensured backward compatibility for v3.0 clients so that they can continue backing up to a v3.1 server (this way, you can upgrade your clients in a phased manner). ALWAYS UPGRADE THE BACKUP (& REPLICATION) SERVERS FIRST.

Migrating from older version to v3.0

Migration from older version to v3.0 is not supported. v3.0 has to be installed as a fresh installation. Migration from v2.5.1 and v2.5.5 to v3.x will be supported in future.

Migrating from version 2.5/2.5.1 to 2.5.5 (for Backup Server and Replication Server only)

To upgrade your Backup Server and Replication Server to Gbackup v2.5.5, you can install Gbackup v2.5.5 on top of the existing v2.5/v2.5.1 Backup Server and Replication Server installations. Gbackup will automatically migrate them to v2.5.5. Before migrating to v2.5.5, please make a note of the following instructions:

• v2.5.5 is released only for Backup and Replication Server installations. It will not install over Gbackup client installations.
• To upgrade your backup/Replication Server to v2.5.5 SP edition, you should be currently running v2.5/v2.5.1 SP edition. If you are currently running a older version previous to v2.5/v2.5.1, make sure you first upgrade to v2.5.1 and start Gbackup to complete the migration process before installing v2.5.5.
• To upgrade your backup/Replication Server to v2.5.5, just install v2.5.5 on top of v2.5/v2.5.1 installation. DO NOT UNINSTALL v2.5/v2.5.1.
• If you are upgrading Gbackup from v2.5.1 to v2.5.5, please note that Gbackup v2.5.5 Backup/Replication Server uses ODBC Datasources of Client-Server (MySQL) database as the backend database to store the clients' metadata. Make sure you have installed and configured MySQL before installing v2.5.5. Please follow the following URLs to know more about installing and configuring MySQL and other related packages required for v2.5.5

  MySQL installation and configuration guide for Windows
  MySQL installation and configuration guide for Linux

• If you are currently running Gbackup v2.5, then you already have MySQL installed as v2.5 uses MySQL as the backend database. But you need to update the MySQL configuration file my.cnf (for Linux) or my.ini (for Windows) and the MySQL Connector file odbcinst.ini file (for Linux alone) before migrating to v2.5.5. To do this, please follow the below steps :

  1. Stop Gbackup in your backup/Replication Server.
  2. Open the MySQL configuration file /etc/my.cnf (for Linux) or <MySQL Installation Dir>/my.ini (for Windows)
  3. Add the following attributes under [mysqld] section
  1. Save the file.
  2. If it is a Windows machine, you can now restart MySQL Server by going to 'Start -> Run -> services.msc' and right click on 'MySQL51' service and select 'Restart'. If it is a Linux machine, follow the steps 6-10 listed below.
  3. Execute the command 'odbcinst -j'. (Only for Linux)
  4. Note the path of the 'odbcinst.ini' file for DRIVERS. By default, it is '/usr/local/etc/odbcinst.ini'
  5. Open the odbcinst.ini
  6. Append the attribute 'Threading' under [MySQL] section as follows :
  1. Restart MySQL Server. To restart MySQL in Linux, execute the command '/etc/init.d/mysql restart' as root.

[mysqld]
slow_query_log = 1
innodb_flush_method=O_DIRECT (only for MySQL server running in Linux)

[ODBC]
Trace = No
Trace File = /tmp/sql.log
Pooling = Yes

[MySQL]
Description =
Driver = /usr/local/lib/libmyodbc3-3.51.27.so
Driver64 =
Setup = /usr/local/lib/libmyodbc3S-3.51.27.so
Setup64 =
UsageCount =1
CPTimeout =300
CPReuse =1
Threading =0

• After completing installation and configuration of MySQL, start MySQL Server and then upgrade Gbackup to v2.5.5

   

• Upgrading Gbackup from v2.5.1 to v2.5.5 will migrate all the backups' metadata from the embedded SQLite database to Client-Server MySQL database. Gbackup v2.5.5 migration will take time based on the number of clients, backups and number of rows/entries available in the SQLite databases.

   

  As an estimate Gbackup might take 30 to 40 minutes for migrating 1 million records from SQLite to MySQL database based on the system hardware configuration. Hence, if you have 25 million files backed up with around 50 million records in the database, then it might take around 25 hours to migrate the metadata from SQLite databases to MySQL. This time duration could be lesser based on the hardware configuration of your Server.

  Please note that, as the database entries are populated in MySQL Server, the MySQL's innodb file size will increase based on the number of records migrated from the SQLite database. Hence, it is wise to plan the MySQL database storage as well as to optimize InnoDB storage engine for the migration. Please refer the above MySQL installation guide for more details on this.

• From v2.5.5, Gbackup uses separate MySQL database for each backups in the Backup Server/Replication Server for better scalability and performance. Gbackup v2.5 uses a single global database to store the metadata of the all the clients. While upgrading from v2.5 to v2.5.5, you can migrate the metadata of the backups from the single global database to separate databases for each backups. Or you can opt to not migrate the existing backups' metadata to separate databases and to use separate databases only for the future new backups. If you choose the former option, then migration will take time based on the number of clients, backups and number of rows/entries available in the global databases.

• When migration is in progress, if you login to the Gbackup web console, you will see the number of total backups to be migrated, number of backup databases already migrated, number of backup databases which have failed migration, number of replication databases already migrated and number of replication databases which have failed migration.

   

  Please do not stop/restart Gbackup while migration is in progress.
• If you see any failed backups during migration, please check <Gbackup_HOME>/sgmysqlmigration/failedBackups.xml file for more details. Contact Gbackup support, to import the backups which have failed during migration.

Migrating from version 2.4 to 2.5.1

You can install Gbackup v2.5.1 on top of the existing version 2.4 and Gbackup will automatically migrate to v2.5.1. Before migrating to v2.5.1, please make a note of the following instructions:

• To upgrade to v2.5.1, you should be currently running the v2.4.

• To upgrade to v2.5.1, just install v2.5.1 on top of the v2.4 installation. DO NOT UNINSTALL v2.4.

• If you are currently running a previous version, make sure you first upgrade to v2.4 and start Gbackup to complete the migration process before installing v2.5.1.

Also ensure that your Backup Server is running the same (or higher) version than the clients backing up to it. For example: before upgrading clients to v2.5.1, you must ensure that your Backup Server has been upgraded to v2.5.1; we typically ensure backward compatibility for clients, for example, a v2.4 client can still backup to a v2.5.1 server (this way, you can upgrade your clients in a phased manner). In short, ALWAYS UPGRADE THE BACKUP (& REPLICATION) SERVERS FIRST.

Versions previous to v2.4 cannot be migrated directly to v2.5.1. If you are running Gbackup version older than v2.4, follow the migration steps given in "Migrating from version 2.3.5 to 2.4" section below.

Migrating from version 2.3.5 to 2.4

You can install Gbackup v2.4 on top of the existing version 2.3.5 and Gbackup will automatically migrate to v2.4 release. Before migrating to v2.4, please make a note of the following instructions:

• To upgrade to v2.4 SP edition, you should be currently running the v2.3.5 SP edition.

• To upgrade to v2.4, just install v2.4 on top of the v2.3.5 installation. DO NOT UNINSTALL v2.3.5.

• If you are currently running a previous version, make sure you first upgrade to v2.3.5 and start Gbackup to complete the migration process before installing v2.4.

Also ensure that your Backup Server is running the same (or higher) version than the clients backing up to it. For example: before upgrading clients to v2.4, you must ensure that your Backup Server has been upgraded to v2.4; we typically ensure backward compatibility for clients, for example, a v2.3.5 client can still backup to a v2.4 server (this way, you can upgrade your clients in a phased manner). In short, ALWAYS UPGRADE THE BACKUP (& REPLICATION) SERVERS FIRST.

Versions previous to v2.3.5 cannot be migrated directly to v2.4. You will have to first migrate them to v2.3.5 and install v2.4 on top of it. For versions previous to v2.2.1, first migrate them to v2.2.1 and to v2.3 and then to v2.3.5.

Migrating from version lower than 2.3.5

If you are currently running a version previous to 2.3.5, then you need to first upgrade to v2.3.5 before installing v2.4.

It is very important that after every version upgrade, you need to start the Gbackup application and login into the web console and confirm the upgrade has happened successfully before upgrading it to the next version. !!!!

As an example, if you are currently running Gbackup v2.2, then you need to follow the steps given below to upgrade to v2.4

1. Install Gbackup v2.2.1 build on top of the existing v2.2 installation.

2. Choose 'Start Gbackup' option after completing the installation and wait for some time to let the Gbackup application to complete the migration. If you log into the web console while the migration is in progress, you will be redirected to page that indicates the migration is in progress.

3. Once the migration process is completed, login to the web console and verify all the configurations and backups are intact - VERY IMPORTANT

4. Install Gbackup v2.3 build on top of the existing v2.2.1 installation.

5. Choose 'Start Gbackup' option after completing the installation and wait for some time to let the Gbackup application to complete the migration.

6. Once the migration process completed, login to the web console and verify whether all the configurations are intact - VERY IMPORTANT

7. Install Gbackup v2.3.5 build on top of the existing v2.3 installation.

8. Choose start Gbackup option after completing the installation and wait for some time to let the Gbackup application to complete the migration.

9. Once the migration process is completed, login to the web console and verify whether all the configurations are intact - VERY IMPORTANT

10. Install Gbackup v2.4 build on top of the existing v2.3.5 installation.

11. Choose start Gbackup option after completing the installation and wait for some time to let the Gbackup application to complete the migration.

12. Once the migration process is completed, login to the web console and verify whether all the configurations are intact - VERY IMPORTANT

Migrating from version 2.3 to 2.3.5

You can install Gbackup v2.3.5 on top of the existing version 2.3 and Gbackup will automatically migrate to 2.3.5 release.

Versions older than v2.3 cannot be migrated directly to v2.3.5. You will have to first migrate them to v2.3 and install v2.3.5 on top of it. For versions older than v2.2.1, first migrate them to v2.2.1 and then to v2.3.

If you login into the web console when the migration process is in progress, you will be directed to a page which indicates that migration is in process. The migration might take up to 20 minutes depending upon the amount of data to be migrated. Wait for some time and then try re-logging in. Please don't shutdown and restart Gbackup as this will only further delay the migration.

Migrating from version 2.2.1/2.2.5 to 2.3

You can upgrade Gbackup v2.2.1and v2.2.5 to v2.3 by just installing v2.3 on top of the current installation. Versions older than v2.2.1 cannot be migrated directly to v2.3. You will have to first migrate them to v2.2.1 and then migrate v2.2.1 to v2.3.

Migration might take some time depending upon the amount of data to be migrated. Please don't restart Gbackup as this will only further delay the migration. If you log into the Gbackup web console during migration, you will be directed to a page indicating that the migration process is in progress. Wait for sometime and then try logging back in. In the Backup Server. migration could take about 5 minutes for every 100,000 files backed up. Migration in the client should not take much time.

Migrating from version 2.2.1 to 2.2.5

There is no special migration procedure if you are updating from 2.2.1 to 2.2.5. You can just install Gbackup 2.2.5 on top of the existing 2.2.1 version and Gbackup will automatically migrate to the 2.2.5 release. Gbackup will not be functional while the migration is in progress. The migration on the Gbackup may take some time based on the number of files backed up to/from the Gbackup installation, as Gbackup performs indexing on the internal databases to improve performance of backups during migration. For example, migrating 1,000,000 files will take about 10 minutes and 2,000,000 files will take about 20 minutes. While you update from Version 2.2.1 to 2.2.5 please note that:

1. Gbackup will not be able to schedule any backups while the migration is in progress.

2. The Gbackup Web Console, when accessed, will come up with a message that "Migration is in progress". Gbackup Web Console features cannot be used while the migration is in progress.

 

Migrating from version 2.0/2.0.1/2.1/2.1.1 to 2.2/2.2.1

Migrating to Gbackup 2.2/2.2.1 is completely automatic except for the case where a Backup Server has multiple clients (under different customers) with the same Gbackup id.

All you have to do is to install Gbackup 2.2.1 on top of your existing (2.0/2.0.1/2.1/2.1.1) Gbackup installation.

Please migrate your Backup Server & Replication Server first. Thereafter, you can migrate your clients in a phased manner. Clients running version 2.0/2.0.1/2.1/2.1.1 will continue to backup to your Backup Server running v2.2.1 ! Section 1 below covers Server Side Migration, and Section 2 covers Client Side migration.

1. Gbackup Server-side Migration

While updating a Gbackup server installation to version 2.2, most of the migration procedures are internal and automatic. The migration on the Gbackup Backup Server and the Gbackup Replication Server may take some time based on the number of files backed up on the Gbackup Server. For example, migrating 100,000 files will take about 10 minutes and 200,000 files will take about 20 minutes.

While updating a Gbackup server installation to version 2.2, most of the migration procedures are internal and automatic. But the following changes to Gbackup 2.2 needs to be understood by the service provider before deploying and using Gbackup 2.2

.

1.1. Gbackup 2.2 customer and license (MSPEU) migration

From Gbackup 2.2, all client licenses are managed from the Backup Server and there is no need to apply license keys to the Gbackup clients backing up to the Backup Server. The client license unit in Gbackup 2.2 is called an MSPEU (monthly SPEU). The pre-2.2 license units were called SPEUs. 1 SPEU is simply 12 MSPEUs. When you update your existing installation to Gbackup 2.2, Gbackup will automatically migrate all the pre-2.2 licenses added under customers to the new MSPEU license scheme. The number of migrated MSPEUs are calculated based on the expiry date of each of the SPEU licenses (pre-2.2), license type (Desktop/Server) of each of the clients backing up to the server. The following points are to be noted on how the customer and license migration is done in 2.2:

1. The licensed (therefore, paying) clients under the 'Trial Customer' in existing Gbackup versions (2.0/2.0.1/2.1/2.1.1) will be migrated to the 'Default Customer' in Gbackup 2.2 ; 'Default Customer' is a new group in v2.2 to accommodate paying/licensed clients that are not categorized under any specific customer.

2. The (non paying / unlicensed) trial clients under the 'Trial Customer' in existing Gbackup versions (2.0/2.0.1/2.1/2.1.1) will continue to be retained under the 'Trial Customer' in Gbackup 2.2.

3. The pre-2.2 licenses which were added under different customers (in the Gbackup Server) will be migrated to MSPEUs in Gbackup 2.2 and they will be automatically assigned to the respective customers.

4. The licenses (for licensed clients) added under the 'Trial Customer' will be migrated to MSPEUs and will be automatically assigned to the 'Default Customer'. By default, after 2.2 migration, all customers, except 'Trial Customer', will be configured to "Automatically use MSPEUs as required". This way, the clients under each of the customers will automatically use MSPEUs from the global MSPEU pool as and when required.

1.2. Gbackup 2.2 invoice migration

Gbackup 2.2 has the concept of invoice plans wherein you can create multiple invoice plans and assign an invoice plan to one or more customers. The following points are to be noted on how the invoice module is migrated to Gbackup 2.2.

1. Customer Invoice Configurations for each Customer in Gbackup 2.1.1 will be migrated as Invoice Plans in 2.2. The migrated Invoice Plans will be automatically assigned to the respective Customers. For example, if the Customer name is 'Test Customer', then a Invoice plan with a name 'Test Customer-Plan' will be created and will be assigned to 'Test Customer'.

2. By default, the 'Default Invoice Plan' will be assigned to the 'Trial Customer' after 2.2 migration.

1.3. Migration of clients with duplicate Gbackup Id to Gbackup 2.2

One big change in Gbackup 2.2 is that, from Gbackup 2.2, all the clients backing up to a Gbackup server across all customers should have a unique Gbackup Id. If there are multiple clients with the same Gbackup Id across different Customers in 2.1.1, then these clients cannot be migrated 'as is' to Gbackup 2.2. In this case, except for one of the clients, all other clients with the same Gbackup Id will have to be manually renamed or completely deleted from the Gbackup server.

During migration Gbackup 2.2 will automatically detect clients with same Gbackup Id. After the migration is done, when you login to the Gbackup server webconsole, you will be given options to individually handle the migration of clients with the same Gbackup Id (if at all any exist). The clients with the same Gbackup Id will be listed with their Customer Name in the webconsole. And you can do one of the following for each of the clients:

1. Rename the client and continue migration - If this option is selected, then the client will be migrated with the new client name provided.
2. Delete this client and continue migration - If this option is selected, then the client & their data will be deleted from the Backup Server.
3. Leave this client as it is and continue migration - If this option is selected, then the client will be retained with the same name. Note that you can choose this option for only one of the clients, i.e., if one client is being retained 'as is', other clients with the same name will need to be deleted/renamed.

Note that you will not be able to login to the webconsole until the migration of the duplicate clients in Gbackup 2.1.1 is completed. You can view the status of the clients' migration after clicking the 'Migrate' button. You will be able to login to the Gbackup Webconsole only after successful migration of the duplicate clients.

VERY IMPORTANT: You should ensure that the Gbackup clients whose Gbackup Ids have been renamed should not be started until they are updated to Gbackup 2.2 and their Gbackup Ids changed to the same Id (as renamed to) in the server. Please ensure that this is done as otherwise you may have multiple clients (with the same name) continuing to backup to 1 client account in the Gbackup Server.

1.3.1. Renaming Gbackup Id in the Gbackup client side

After doing the duplicate client migration (if you did indeed have duplicate clients in the first place) on the Backup Server, you will need to change the Gbackup Identity in the Gbackup client. To do this, update the client to Gbackup 2.2 by installing Gbackup 2.2 on top of the existing installation. After installation, do not start the Gbackup client until the client's Gbackup Id is changed to the same name configured in the Backup Server.

To change the Gbackup Identity of the client, please follow the below steps :

1. Open a terminal or command prompt.
2. Go to the <Gbackup_HOME> directory.
3. In case of Windows client, execute the command 'bin\StoreGrid.exe ChangeIdentity <Old Gbackup Identity> <New Gbackup Identity>'.
4. In case of Linux client, execute the command './bin/Gbackup ChangeIdentity <Old Gbackup Identity> <New Gbackup Identity>'.

This will migrate the Gbackup Identity of the client with the new client name. After changing the Gbackup Identity you can start Gbackup normally.

2. Gbackup Client-side Migration

Gbackup 2.2 will automatically update itself on top of an existing previous Gbackup installation. There are no special migration steps in the client side. But if during the server side migration, the client's Gbackup Id has been changed to enforce uniqueness of Gbackup Identities, then the Gbackup client should not be started until the Gbackup Id in the client side is also changed to the same Id configured in the server side.

IMPORTANT: You should ensure that the Gbackup clients whose Gbackup Ids have been renamed in the server-side should not be started until they are updated to Gbackup 2.2 and their Gbackup Ids changed to the same Id as in the server. Follow the steps in 1.3.1 above to change the client's Gbackup Id before you start the Gbackup client.

NOTE: The Email Filtering configurations are not migrated from 2.1.1 to 2.2.1. Hence, please reconfigure the Email filtering options after upgrading to Gbackup 2.2.1 Release.

Migrating from version 2.0/2.0.1/2.1 to 2.1.1

There is no special migration procedure if you are updating from 2.0/2.0.1/2.1 to 2.1.1. You can just install Gbackup 2.1.1 on top of the existing 2.0/2.0.1/2.1 version and Gbackup will automatically migrate to the 2.1.1 release. Gbackup will not be functional while the migration is in progress. But the migration itself will take only a few seconds. While you update from Version 2.0.1/2.1 to 2.1.1 please note that:

1. Gbackup will not be able to schedule any backups while the migration is in progress.

2. The Gbackup Web Console, when accessed, will come up with a message that "Migration is in progress". Gbackup Web Console features cannot be used while the migration is in progress.

 

Migrating from version 1.6 to 2.0

Gbackup 2.0 is a major upgrade release over the Gbackup 1.6 release. Gbackup's architecture and infrastructure have been revamped and improved significantly keeping in mind scalability, performance and flexibility in terms of evolution of future versions of Gbackup. Towards that end, Gbackup 2.0 completely leverages an embedded RDBMS both in the client and the server side. Except for the backup files, which uses the native file system itself, every other information Gbackup generates or uses like configurations, file meta-data, file signatures, events, version information, backup reports, restore reports etc. are all driven from the RDBMS. Leveraging an RDBMS gives Gbackup the capability to evolve rapidly in terms of new features and user-interface improvements etc. without compromising on scalability and performance. With this major re-design of Gbackup with the 2.0 version, we expect to deliver customer focused features at a more rapid pace than before.

Whether Gbackup installation is a Client, Server, Or Client-Server Installation, the first time it runs, Gbackup 2.0 automatically migrates all the file meta-data and configurations maintained in flat files or the 1.6 database to the newly created 2.0 database. The Gbackup Client side migration is quite fast. Even for 1000s of files, the client side migration will take only a few minutes. On the Gbackup server side, where the backup data is present, depending upon the number of files you have backed up earlier, the migration may take some time. The time taken for the migration on the server side depends upon the total number of files that were earlier backed up with Gbackup 1.6. Migrating 10,000 files will take about 4 minutes and 100,000 files will take about 40 minutes.

Gbackup will not be functional while the migration is in progress. While you upgrade from Version 1.6 to 2.0, please note the following points:

1. Gbackup 2.0 will automatically migrate your 1.6 data to 2.0 formats when it runs first time after the upgrade.

2. Gbackup 2.0 is not interoperable with Gbackup 1.6. Hence make sure you upgrade and migrate both your client and server installations before you resume your backups. The recommended procedure is to update and migrate your Gbackup servers first. Gbackup 2.0 will put all the backup schedules in the client in suspended mode after the migration process.You need to resume them manually after making sure the backup servers also have been upgraded and migrated to 2.0.

3. Gbackup will not be able to schedule any backups while the migration is in progress.

4. The Gbackup Web Console, when accessed, will come up with a message that "Migration is in progress". Gbackup Web Console features cannot be used while the migration is in progress.

5. Gbackup Migration process may use high CPU cycles and may slow down other processes on the machine/PC. Hence it is advisable to upgrade to Gbackup 2.0 when you are not using the machine/PC for CPU intensive tasks.

Advanced Users

The following points should help you understand the internal migration process when you run Gbackup 2.0 for the first time after upgrading from 1.6.

1. Gbackup 1.6 to 2.0 Client Side Migration

    

The operations performed in client side migration are as follows:

1. User Account Migration: Read the user lists from userfiles.lst and write to Client DB.

2. Backup Configuration Migration: List the *.sbf, *.imm & *.scc files from <Gbackup_HOME>/conf & add backup configuration to DB. After migration, the backups will be in suspended status. User has to resume the backup schedule manually only after making sure the backup servers the client was backing up to are also upgraded to the Gbackup 2.0 version and the migration has taken place in those servers.

3. Discovered Peer List Migration: Read the discovery.log (if not present, discovery.tmp) file from <Gbackup_HOME> and add them to Discovery DB.

4. Discovery Configuration Migration: Read the discovery.conf file from <Gbackup_HOME>/conf and write to Discovery DB.

5. Delete Configuration & Reports Migration: List the *.sdf files from <Gbackup_HOME>/conf & write them to Client DB.

6. File Meta Data Migration: Attach the 1.6 DB to 2.0 DB and copy the file meta-data information and signature data.

7. Backup Reports Migration: Attach the 1.6 DB to 2.0 DB and copy the backup reports information.

8. Restore Reports Migration: List the *.rpt files from <Gbackup_HOME>/report/restore and add them to DB.

The operations performed in server side migration are as follows:

1. For each backup client backing up to the server, find the backup location from <INSTALLATION_HOME>/conf/diskspaceconfiguration/and migrate the backed up files to a new 2.0 directory structure which is based on directory Ids. Note that Gbackup 2.0 will move the backed up files from the original location to the new location.

    

2. By default all the client's backup will be done under a directory called "1" under the backup location.

    

3. Move Disk Space Configuration information of all clients to Server DB.

    

 

Migrating from version 1.2.1 to 2.0

If you are still using the 1.2.1 release and want to migrate from 1.2.1 to 2.0, then the migration is a two step process.

1. Firstly you need to migrate from 1.2.1 to 1.6 by installing Gbackup 1.6. You can check whether the migration has completed by logging into the UI. The steps for migrating from 1.2.1 to 1.6 is given below.

2. After migrating to 1.6, then you can migrate Gbackup to 2.0 by installing 2.0 on top of the 1.6 version. The steps for migrating from 1.6 to 2.0 is given above.

Migrating from version 1.2.1 to 1.6

NOTE: Gbackup 1.6 is a minor bug fix release over 1.5.1. So there is no special migration procedure if you are updating from 1.5.1 to 1.6

Gbackup 1.6 has some significant improvements in terms of how a Gbackup client internally maintains metadata information.

In earlier versions , metadata information like the signature (used for incremental backups) and file statistics (modified time, created time etc.) were stored in flat files. This was relatively inefficient as the metadata occupied more space than necessary. Gbackup 1.6 uses an embedded relational database (RDBMS) to store the metadata efficiently. Moving to an RDBMS also enhances Gbackup's ability to provide more detailed reports.

The first time it runs, Gbackup 1.6 automatically migrates the metadata maintained in flat files to the embedded RDBMS. Depending upon the number of files you had backed up earlier, the migration may take some time. The time taken for the migration depends upon the total number of files that were earlier backed up with Gbackup 1.2.1. Migrating 10,000 files will take about 2 minutes and 100,000 files will take about 30 minutes.

Gbackup will not be functional while the migration is in progress. While you update from Version 1.2.1 to 1.6 , please note that:

1. Gbackup will not be able to schedule any backups while the migration is in progress.

2. The Gbackup Web Console, when accessed, will come up with a message that "Migration is in progress". Gbackup Web Console features cannot be used while the migration is in progress.

3. Gbackup Migration process may use high CPU cycles and may slow down other processes on the machine/PC. Hence it is advisable to update to Gbackup 1.6 when you are not using the machine/PC for CPU intensive tasks.

4. The last backup information in the backup reports will be reset after the migration, i.e. the last backup information like Total Files, Total Files Protected etc. will be set to zero. These fields will be updated once Gbackup 1.6 runs and completes a backup.

For Advanced Users

The following points should help you understand the internal migration process when you run Gbackup 1.6 for the first time after updating from 1.2.1

1. Gbackup 1.6 creates a relational database file "storegrid.db" in <INSTALLATION_HOME>/Gsolutions/Gbackup/data directory.

2. The 1.2.1 version metadata information available in the <INSTALLATION_HOME>/Gsolutions/Gbackup/data/<backup-schedule> directory will be copied to the relational database. At the end of migration of every backup schedule, Gbackup will rename the existing backup schedule metadata directories to <backup-schedule>_SG_1_2_1. Gbackup 1.6 will not delete the 1.2.1 version's meta data information. All the directories renamed with _SG_1_2_1 can be deleted by the user manually after making sure Gbackup 1.6 works correctly after the migration process.

3. Gbackup 1.6 will also migrate the reports available under <INSTALLATION_HOME>/Gsolutions/Gbackup/report/backup to the relational database.

4. In case Gbackup is terminated during migration, Gbackup will migrate the remaining metadata the next time Gbackup is restarted.