Post Upgrade

Post Upgrade Notes

Backup Set Index Conversion

A new index system is introduced in AhsayCBS v8.3.0.0 or above to provide better backup performance and robustness. The backup set index conversion will take place for all v6, v7 and pre-v8.3 AhsayOBM/AhsayACB backup sets after upgrading to v8.3.0.0 or above. Index conversion cannot be disabled. An index conversion process will be performed on the backup set on the first backup job immediately after the upgrade. The old v6 files: index.bdb and r-index.bdb will be converted to the new index file structure: index.db* and backupInfo.db*. While the old v7 and pre-v8.3 files: index.b2b*, index.xml* and index-s0* will also be converted to the new index file structure: index.db* and backupInfo.db*. Temporary space needed for index conversion is 200% of the uncompressed index file. You will need 100% for the old index file and another 100% for the new index file. After the index conversion, for large data index the new index will be smaller since duplicated information will be grouped. But for small data index, the new index might be larger since additional information may be included in the new index.

The index conversion process may only take a few minutes for backup sets with a small number of files. For example: MS SQL Server, MySQL server, MS Exchange database, Oracle database, VMware, Hyper-V, Windows System State, Windows System backup, Lotus Domino etc.

However, for backup sets which could contain large number of files and folders, the v8.3 index conversion process could take several hours to complete. For example: File, Cloud File, MS Exchange mail level and Microsoft 365 backup sets. In some cases, backup sets containing several millions of files/folders could take days to complete the v8.3 index conversion process. Please take this into consideration when planning your AhsayOBM/AhsayACB client upgrade to v9.1.0.0 or above.

Periodic Data Integrity Check (PDIC)

After AhsayOBM/AhsayACB is upgraded to v9.1.0.0 or above, from v6, v7, or pre-8.3.4.x version; on the first backup job after upgrade, a mandatory PDIC job will be triggered to verify the integrity of the data and index. Depending on the number of files and jobs in the backup set, this process could take some time to complete.

Here is a diagram of the Periodic Data Integrity Check process.

After the mandatory PDIC job, the PDIC will then run on the first backup job that falls on the corresponding day of the week from Monday to Friday which is the schedule that will be followed determined automatically by the result of the following formula:

PDIC schedule = %BackupSetID% modulo 5
or
%BackupSetID% mod 5 

This schedule was created to minimize the impact of the potential load of large number of PDIC jobs running at the same time on the AhsayCBS server. The calculated result will map to a corresponding day of the week (i.e. from Monday to Friday).

Example:

Backup Set ID: 1594627447932

Calculation: 159462747932 mod 5 = 2

In this example:

• The PDIC will run on the first backup job that falls on a Wednesday; or
• If there is no active backup job(s) running from Monday to Friday, then the PDIC will run on the next available backup job.

Consult the Periodic Data Integrity Check Process section of either the AhsayOBM or AhsayACB guides for additional details.

Mapping of Region for Google Cloud Storage

The following table shows the mapping for the multi-regional location type before and after v8.5.0.0+ upgrade.

The following table shows the specific locations for each location type.

Two-Factor Authentication for Twilio Users in AhsayCBS v8.5.0.0 or above

Since Mobile Authentication is introduced in AhsayCBS v8.5.0.0 or above to provide additional security for user accounts, Twilio is deprecated; users who are using Twilio Credentials Verification for Two-Factor Authentication may continue using it. Upon upgrade, the existing Twilio Credentials setup will be automatically migrated.

However, only one type of Two-Factor Authentication may be enabled. You cannot use both at the same time, so you have to choose which type you would use. If you decide to use Mobile Authentication instead, once you enable it, Twilio Credentials Verification will automatically be deleted and it is not possible to re-enable it at a later date.

To enhance security, the recovery email feature for Twilio users has been removed.

It is recommended you convert to TOTP 2FA instead of continued use of Twilio, as Twilio support has ceased.

For more information please refer to the Twilio section found in the System Settings section.

Run on Server (Agentless) Microsoft 365 and Cloud File Backup Port Requirement

When upgrading AhsayCBS v6, v7 and pre-v8.3.4.42, due to enhancement to the AhsayCBS Run on Server backups an additional connector has been added. The default port 8081 on local IP address 127.0.0.1 is used for Run on Server (Agentless) Microsoft 365 and Cloud File backup. This is automatically setup upon installation but is not visible from System Settings > Basic > General > Connectors to prevent users from editing or deleting it. However, it can be checked in the server.xml file which is located in the $APPLICATION_HOME\conf folder.

If the default port is occupied, then AhsayCBS will automatically acquire the next available free port from 8081 to 9080. If all ports in that range are occupied, then AhsayCBS service is stopped.

Mobile Licensing

To support the new Ahsay Mobile app, the Ahsay Mobile licenses will be listed under Mobile Add-on Modules which are free of charge and each license key is assigned an unlimited quota.

The Mobile Add-on Modules are required by an AhsayOBM/AhsayACB user if they are using the Ahsay Mobile app for Android and iOS backups. If the Ahsay Mobile app is only used for Two-Factor Authentication (2FA) purposes, then the Mobile license modules are not required.

Each AhsayOBM/AhsayACB user account is currently limited to 10 Mobile CALs.

Backup and Restore Reports

The composition of email reports that will be sent has changed starting with AhsayCBS v8.5.2.42 or above. If the size of the PDF report is less than 10MB, the PDF report will be attached in the email. However, if the size of the PDF report is greater than 10MB (fixed), the PDF report will not be attached in the email. Instead, a download link will be available for the user to download the PDF report. This fixed 10MB value limit is not customizable.

This was changed to ensure that emails will be received by the user by making sure that it will not be blocked by SMTP server due to email size is too big. This will also help in managing the capacity of the clients’ mailbox by making sure that the email sent does not take up too much space.

Here is a sample of an email that will be received if the PDF report is less than 10MB.

And here is a sample of an email that will be received if the PDF report is greater than 10MB.

Multiple Threads Replication

The calculation for maximum number of replication threads has been changed starting from AhsayCBS v8.3.2.11 or onwards. Instead of using the number of CPU cores in the calculation, this is replaced by the number of CPU sockets. The new formula is:

Maximum number of replication threads = total number of CPU sockets

For example, an AhsayCBS server with 2 CPU’s will have a maximum of two concurrent replication threads.

This is different from the previous AhsayCBS versions where the number of CPU cores determines the maximum number of replication threads. The formula for previous AhsayCBS versions is:

Number of concurrent backup set to replicate = [Total CPU Cores] / 8

For example, an AhsayCBS server with 8 CPU cores will have a maximum of one concurrent replication thread.

The minimum number of replication thread is 1 while the maximum is 4.

The previous calculation method meant a higher number of replication threads were available. However, on some low-mid range server hardware and storage configurations this had a negative impact on AhsayCBS backup server due to an increased server load, which ultimately affected overall server performance (backup, restore and replication).

There is an option to increase the maximum number of replication threads to equal the number of CPU cores for underutilized AhsayCBS backup servers running on high performance hardware and storage configurations with spare network bandwidth capacity. For example, an AhsayCBS server with a single CPU with 8 cores, will be able to get up to 8 concurrent replication threads. For more information regarding this please refer to the Replication section.

Ahsay Download Page

With the release of AhsayCBS v8.5.2.0 and above, the layout of the installer download page has been improved for better clarity with the supported installer type listed.

For more details on the new AhsayCBS Download page, refer to the Branding section.

v6 Backup Set Data Migration

Legacy v6 Backup Data Migration page has been removed. AhsayCBS v9 will automatically convert v6 backup data, to the v9 AhsayCBS Blocks data format (32MB/64MB), for any user’s backup sets running on v9 AhsayOBM/AhsayACB client. You should closely monitor your User Home disk usage, as there is no control to suspend/pause/exclude v6 Backup Set conversion, and it will require 150% in temporary free disk space of the User Home storage. Any previously excluded Backup Sets will become Enabled, and conversion will proceed when user is running v9 client.

cbs.db

Starting with AhsayCBS v9.1, Auto Update settings are stored in %AhsayCBS_HOME%/conf/cbs.db , along with pending email reports, computer information, Run on Server job status.

Branding Profile

Starting with AhsayCBS v9.5, branding profiles stored in %AhsayCBS_HOME%/conf/Branding/*.json has been replaced with %AhsayCBS_HOME%/conf/cbs.db and %AhsayCBS_HOME%/conf/Branding/{ID} (where {ID} is “ROOT” or the SubAdmin ID#).

Deduplication

Starting with Ahsay v9, the In-File Delta feature (that offers Incremental, Differential, and Full backups) will be replaced with Deduplication.

Deduplication is part of the backup process that identifies and eliminates duplicate copies of repeating data, storing it once, in order to save storage space. Deduplication plays a major role in managing storage space, particularly when performed over large volumes of data.

With it enabled, your user’s backup data will be optimized, and you will see significant storage usage decrease when compared to previous AhsayCBS version, resulting in more data stored and better storage ROI.

With it disabled, backup data will be similar to Full backup jobs.

Deduplication is an assignable AhsayCBS standard license module, and Deduplication module applied per User by default.

More details are found in the Overview section and v9 New Features Datasheet.

"Migrate Data" Migration for v9 Deduplication Compatibility

Migrate Data is the conversion of pre-AhsayCBS v9 data blocks from AhsayCBS v7 / v8 Backup Sets now running on v9 client (AhsayOBM/AhsayACB). For users still running pre-AhsayCBS v9 agents, they will continue to use In-File Delta technology (Full/Incremental/Differential) and Migrate Data does not apply.

"Migrate Data" for v9 Deduplication, will reupload changed Source data at time of backup storing the reupload as v9 data blocks. It will temporarily require up to double the destination’s storage to convert pre-AhsayCBS v9 data blocks into the new v9 Deduplication-compatible blocks. Source data that is unchanged, will not be reuploaded therefore not use additional space, and remain as pre-AhsayCBS v9 data blocks as no Migrate Data will take place for already backed up data. Both pre-AhsayCBS v9 and AhsayCBS v9 data blocks can be used during Restore jobs.

AhsayCBS Admin should monitor user’s storage Quota, which will be affected by the increased usage caused by Migrate Data.

Temporary space that was used for Migrate Data will be reclaimed according to the backup set's Retention Policy cleanup setting. For backup sets with long Retention history, the storage cannot be reclaimed until the threshold has exceeded. This should be considered when users have lengthy Retention Policies.

Setting up Memory for Run on Server (Agentless) Backups

Starting with AhsayCBS v8.3.4.0 or above, the Run on Server (Agentless) Microsoft 365 and Cloud File backup job has its own Java process independent from the main AhsayCBS Java process. For upgraded AhsayCBS with existing Run on Server Microsoft 365 and Cloud File backup sets it is strongly recommended to:

• Reduce the Java heap size of the main AhsayCBS Java process to free up memory so it can be re-allocated to the individual Run on Server (Agentless) Microsoft 365 and Cloud File backup job. For information on how to do this, please refer to this article How to Modify the Java Heap Size on AhsayCBS.
• Setup Java heap size for the individual Run on Server (Agentless) Microsoft 365 and Cloud File backup jobs if required. In general, the default setting 2048M or 2GB of maximum Java heap size and 128MB of minimum Java heap size should be adequate. To change the Java heap size setting of individual Run on Server (Agentless) Microsoft 365 backup job, please refer to this article How to Modify the Java Heap Size settings for Run on Server Microsoft 365 Backup Job.

However, if the default settings are not adequate, the maximum and minimum Java heap size for each Run on Server backup Java process can be configured by the system administrator by following the instructions below.

In the examples, 2048 (maximum) and 256 (minimum) Java heap size. The size of the Java memory that you will set for each backup job depends on the number of Microsoft 365 user selected in your backup sets and how much RAM your system has.

1. Locate the cbs.opt file.

   • In Windows, it is in the $APPLICATION_HOME\conf folder.

     

   • In Linux/FreeBSD, it is in the /usr/local/cbs/conf folder.

     

   • In AhsayUBS, it is in the /ubs/mnt/eslsfw/obsr/conf folder.

     

2. Open the file, add the options then save.

   com.ahsay.obs.core.job.ServerRunBackup.Xmx=%value%
   com.ahsay.obs.core.job.ServerRunBackup.Xms=%value%

   • Windows

     

   • Linux/FreeBSD/AhsayUBS, use a text editor.

     

3. Restart the AhsayCBS service.

   • Windows

     

   • Linux/FreeBSD

     

   • AhsayUBS

     

Re-authorize Dropbox app

Due to the update of OAuth 2.0 API by Dropbox Inc. these changes have been updated in AhsayCBS v8.5.4.54 or above in respect to handling of existing destination and backup source using Dropbox. For Dropbox predefined and standard storage destinations created on pre-v8.5.4.54 AhsayCBS/AhsayOBM/AhsayACB, as well as Cloud File backup sets for Dropbox, you need to re-authorize the app to continue using it. All related backup/restore will no longer work properly until it is re-authorized.

Here are four ways to do this:

• from the Predefined Destination page
• from the Cloud File Agentless backup set using Dropbox as a backup source
• from Backup Sets page in AhsayOBM/AhsayACB when using Dropbox as a backup source
• from Backup Sets page in AhsayOBM/AhsayACB when using Dropbox as a standard destination

Re-authorize in Predefined Destination

You may check in the Monitoring > Dashboard > To Dos if there are any invalid Dropbox predefined destination that needs to be re-authorized.

You may click the link to be redirected to the Predefined Destination page.

Or you may go to System Settings > Basic > Predefined Destinations. A warning icon will be displayed beside the invalid Dropbox predefined destination.

To re-authorize your Dropbox predefined destination:

1. Click the Dropbox predefined destination. Click confirm to continue.

   

2. Login to your Dropbox account and allow Ahsay access to the files and folders in your account.

   

   

3. Copy and paste the code and click confirm to continue.

   

   

4. The warning icon will now be removed, click Save to finish setup.

   

   The warning will also be gone from the "To Dos" page.

   

Re-authorize in Cloud File Agentless Backup Set using Dropbox as a Backup Source

Re-authorizing Dropbox for Cloud File Agentless backup sets may be done in AhsayCBS or AhsayOBM/AhsayACB.

1. A warning will be displayed when you try to access a backup set using Dropbox as a backup source. Click confirm to continue.

   

   This warning will also be displayed if you access the backup set in AhsayOBM/AhsayACB.

   

2. Follow step 2 and 3 above to finish the setup.

Re-authorize in Backup Sets Page in AhsayOBM/AhsayACB when using Dropbox as a Backup Source

Re-authorizing Dropbox for Cloud File Agent-based backup sets may be done in AhsayOBM/AhsayACB or AhsayCBS. Steps in doing this is similar for AhsayOBM and AhsayACB, we will be using AhsayOBM as an example for the instructions.

1. A warning will be displayed when you try to access a backup set using Dropbox as a backup source. Click Continue.

   

   This warning will also be displayed if you access the backup set in AhsayCBS.

   

2. Login to your Dropbox account and allow Ahsay access to the files and folders in your account. Copy and paste the code, then click OK to continue.

3. Click Save to finish the setup.

   

Re-authorize in Backup Sets Page in AhsayOBM/AhsayACB as a Standard Destination

1. A warning will be displayed when you try to access a backup set using Dropbox as a standard destination. Click Continue.

   

2. Click the Dropbox destination that needs to be re-authorized then click Continue.

   

   

3. Login to your Dropbox account and allow Ahsay access to the files and folders in your account. Copy and paste the code, then click OK to continue.

4. Click OK then Save to finish the setup.

   

   

Post Upgrade Tasks (Optional)

Branding on AhsayCBS

If you are already on AhsayCBS v7.17.2.2 or above, all your existing branding will be carried forward to the latest version in the previous upgrade steps.

Exceptions are customized cbs.css, which may need to be redone using the latest CSS file. Also, any manually customized LIB properties or Email HTML template files, will need to use the latest CBS versions and edits redone.

However, as with each new release, there may be new branding properties or image requirements. After upgrade, you should review your branding settings, and update accordingly.

In order to build Branded CBS or Branded Clients, you must have had purchased the Rebrand Option module, which then covers any licenses under your account. And you must continue to maintain valid Support maintenance.

After upgrading your AhsayCBS, you will need to generate the client installers again by following the instructions below:

1. Logon to the AhsayCBS web management console.
2. Go to System Settings > Basic > Administrative Access.

3. Click on alphabetically first Admin-type user. (Example, “admin” instead of “system”).

   If you have branded sub-admin, you will need to repeat these steps individually or use the “Administrative Access” | Build view, to bulk build several sub-admin’s client installer simultaneously.
4. Go to the Rebrand Clients page.

5. Review and verify your branding text properties and all custom images.

   If you made changes, remember to Save all the way through to main menu, then return to continue with next step.

6. Go to the Build Installers tab, click the Build Branded Client button to generate branded "OBM" and "ACB" installers.

   Please be patient, the client installer generation process should take around 15 to 30 minutes. However, the generation time would depend on the traffic condition on the Ahsay customization engine; during new release there may be a spike in builds which will queue up your process. The page will display your wait time. However, if that page is frozen and after 60 minutes you may want to contact Ahsay.

   After the installer is generated. You can download branded “OBM” and “ACB” from the Download page for validation testing, before reenabling AUA for each user.

   For further information on how to brand the AhsayCBS interface, reseller interface or AhsayOBM/AhsayACB installers, please refer to the Branding section for details.

Microsoft 365 Customization

For AhsayCBS v8.5.0.0 or above, Microsoft 365 Backup Customization (formerly “Office 365 Backup Customization”) has been added. It allows for customization of Authorization code and Admin consent endpoint screens for the Microsoft 365 Global region which is displayed when creating Microsoft 365 backup sets on AhsayCBS/AhsayOBM/AhsayACB. You must first set it up in Backup / Restore > User, Groups & Policies > Policy Group > %policy_name% > Backup Set Settings > Microsoft 365 Backup Customization. For more information on how to do this please refer to the Administration - Backup / Restore section.

Ahsay Mobile

Ahsay Mobile has been released which can be used to backup photos, videos, documents and 2FA accounts on a mobile device. It can also be used for Two-Factor Authentication. Currently the branding of Ahsay Mobile can only be done by Ahsay. If you are interested in branding the Ahsay Mobile, you must engage our Ahsay Mobile Branding Service. Please contact our sales team to obtain a service quotation by email at sales-kb@ahsay.com or call our International Sales Hotline +852 3580 8091.

Free Trial Registration and Save Password Customization

While for AhsayCBS v8.5.2.35 or above, there are two additional GUI features that can be customized for AhsayOBM/AhsayACB. These are the Free Trial registration and Save password options. The Free Trial registration option can now be either displayed or hidden from the startup page. While the Save password option can also be either displayed or hidden from the login page and Profile > Authentication page. This can be customized in System Settings > Basic > Administrative Access > %system_user_name% > Rebrand Clients > Application Settings – AhsayOBM and System Settings > Basic > Administrative Access > %system_user_name% > Rebrand Clients > Application Settings – AhsayACB.

Hiding the VM Run Direct Tile on AhsayCBS User Web Console

For partners who do not offer VMware backups and/or do not provide VM Run Direct recovery from AhsayCBS, the VM Run Direct Tile on the AhsayCBS User web console can be hidden by editing the cbs.css file which is located in the $APPLICATION_HOME\webapps\cbs\include folder. For details on how to do this please refer to the Branding section.

Hotfix Installation

Ahsay Hotfix Release Program is part of our continuing efforts to provide our partners with quick resolutions for reported software issues. You may actively review the changelog and download the latest hotfix via Ahsay Partner Portal. A valid partner portal login account is required.

This latest page in the Ahsay Partners is updated every Monday and Thursday; except for public holiday when the update will be made on the next available business day.

The AhsayCBS hotfix package includes the AUA components which will allow you to deploy the latest AhsayOBM/AhsayACB hotfixes to supported operating systems using Auto Upgrade. The way the AUA Hotfix works, is the user will need to upgrade to the base release first (ie v9.1.2.0), once upgraded, AUA process will poll the AhsayCBS server for additional binaries (ie Hotfix v9.1.2.64) and upgrade the device on the second-pass.

In order to improve the turnaround time, the hotfixes have been thoroughly tested by our developers, but has not yet passed QA acceptance testing cycles.

Although our developers have made every effort to ensure the stability of the hotfix releases, as a best practice we recommend partners:

1. Conduct some basic testing before rolling out hotfixes to any production systems.
2. Retain a rollback copy of installation prior to deploying hotfix.
3. Deploy hotfixes to only the affected production systems.

If you elect not to install hotfixes, then you may wait for the next public release version which will roll-up earlier hotfix into latest release.