Skip to main content

Features

Here are some key areas that can help make your backup experience a better one.

Web-based Management Console

Enriched features on the centralized user web console offers you a one-stop location for monitoring and managing your backup and restore, whether you are a system administrator or a backup user. Below is an overview of what you can do with it.

  • Create backup set
  • Restore backup
  • Configure user settings
  • Configure backup settings
  • View and download backup and restore reports

Live Activities Monitoring Feature

The AhsayCBS User Web Console has a live activities monitoring feature which is used to keep track of the backup and restore job(s). The following operations can be performed using this feature:

  • View the status of the backup process that is currently running.
  • View the status of the restore process that is currently running.
There is an update interval of around 5 seconds for both backup and restore activities.

No Additional Hardware / Device Required

As the Run on Server (Agentless) backup set utilizes the resources of the AhsayCBS backup server, there is no need to provision additional physical or virtual machine to run the backup/restore, which means the cost of each backup set is much lower than for an agent-based cloud file backup set.

Easy to Manage

The AhsayCBS User Web Console offers you an easy-to-manage user interface. This will help you save time, and it reduces the overall cost of support.

Backup Set Management from Any Device (Accessibility)

Backup/restore operation(s), backup set settings configuration, and backup/restore process monitoring can be done from any device as long as a web browser and internet connection are present in the device.

No AhsayOBM/AhsayACB Client Installation and Upgrades Needed

Upgrading when a newer version becomes available is not necessary, as long as the AhsayCBS server version is upgraded by the backup service provider.

File Transfer Security

The AhsayCBS comes with a secure file transfer method using the https protocol that guarantees the highest level of security measure in safeguarding the movement of files from the backup source (Microsoft 365 / cloud storage) to the backup destination (AhsayCBS server).

High Level of Security

To provide the best protection to your backup data, the encryption feature which by default will encrypt the backup data locally with AES 256-bit truly randomized encryption key is un-hackable.

This will ensure that your data which may contain sensitive information is well protected by using encryption algorithm with the highest level of security measure.

Compliance

Some organizations do not permit the installation of third-party applications on the production environments due to regulatory requirements. An agentless backup and recovery solution allow for compliance during backup or restore.

Less Resources Needed

Backup client agent could interfere with the processing power of core applications of the machines that it is installed on. Run on Server backup job is performed on the backup server, which does not consume resources on client computer during a backup job.

Fast and Efficient

Backup could be a time and resources consuming process, which is why AhsayCBS is designed with advanced technologies to make backup a fast and efficient process.

You may wish to run backup at a specified time interval of your choice, this is where the backup schedule setting comes in, here you can set your own backup schedules so that you can take full control of the time when to perform backup.

Multi-threading technology is also used to produce fast backup and restore performance by utilizing the computing power of multiple CPU cores for creating multiple backup and restore threads.

The default setting for Microsoft 365 backup sets supports a total of 4 threads per backup job.

Default setting with 4 threads per backup job

Higher Reliability

The implementation of one index file per user can significantly improve the overall resilience of backup and restore from index related issues.

One index file per user

For example, if a single index file becomes corrupted, it will only affect corresponding user, while other users selected for backup are unaffected.

Performance (Microsoft 365 only)

The Change Key API has significantly improved backup performance of backup jobs, which means backup sets with a large number of Microsoft 365 accounts for backup can be completed within hours.

Backup of Selected Items (Microsoft 365 only)

To back up the Microsoft 365 user accounts, the backup resources can be user level, site collection level and even item level.

  • Flexible backup options, only select the required users, specific site collections or items for backup.
  • Flexible restore options:
    • Restore all the users or just one user or restore the whole site collection or just one site or restore the whole user content or just one item.
    • Restore items to the original location or an alternate location.

Cloud Destinations Backup

By default, the AhsayCBS is set as the storage destination in creating a backup set. However, you have the option of selecting another storage destination as provided by your backup service provider. Below is a list of supported cloud destinations:

Supported Cloud Destinations

 

Backup Process

To better help you understand what goes on during a backup process, here are the steps performed during a backup job.

Backup Process

For an overview of the detailed process for Steps 3, 5, 10 and 12, please refer to the following:

Periodic Data Integrity Check (PDIC) Process

The PDIC will run on the first backup job that falls on the corresponding day of the week from Monday to Friday.

To minimize the impact of the potential load of large number of PDIC jobs running at the same time on the AhsayCBS server, the schedule of a PDIC job for each backup set is automatically determined by the result of the following formula:

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

The calculated result will map to the corresponding day of the week (i.e., from Monday to Friday).

0Monday
1Tuesday
2Wednesday
3Thursday
4Friday
You cannot change the PDIC schedule.

Example:

Backup set ID: 1594627447932

Calculation: 1594627447932 mod 5 = 2

2Wednesday

In this example:

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

Although according to the PDIC formula for determining the schedule, which is %BackupSetID% mod 5, this schedule only applies if the previous PDIC job was actually run more than 7 days prior.

Under certain conditions, the PDIC may not run strictly according to this formula. For example:

  • The PDIC job will run on the first backup job after upgrade to the latest client version from AhsayOBM v6, v7, or pre-8.3.6.0 version.
  • If backup jobs for a backup set are not run on a regular daily backup schedule (for example: on a weekly or monthly schedule), then the PDIC job will run if it detects that the previous PDIC job was run more than 7 days ago.
  • Every time a data integrity check (DIC) is run, the latest PDIC run date is reset, the next PDIC job will run after 7 days.
  • The PDIC job will not run if there are no files in both the Data and Retention Areas. For example: a newly created backup set with no backup job history or a backup set where all the data has been deleted using the Delete Backup Data feature.
  • The PDIC job will not run on a backup set that contains any data which is still in v6 format. It will only run if all v6 data format on a backup set has undergone data migration to v9 block format.

Periodic Data Integrity Check Process

Backup Set Index Handling Process

To minimize the possibility of index related issues affecting backups, each time index files are downloaded from and uploaded to backup destination(s); the file size, last modified date, and checksum is verified to ensure index file integrity.

Start Backup Job

Start Backup Job

Completed Backup Job

Completed Backup Job

Data Validation Check Process

As an additional measure to ensure that all files transferred to the backup destination(s) are received and saved correctly, both the number of 32 or 64 MB data block files and the size of each block file are checked again after the files are transferred.

Data Validation Check Process

Data Block Size

Before uploading to the backup destination, data will be compressed (if enabled), encrypted (if enabled) and divided into data block size of either 32 or 64 MB. Except for backups using NAS, Synology and QNAP, which will still use 8 - 16 MB data block size.

For example, there are 2 files both having a file size of 15 MB with no compression and deduplication is not enabled. If there are 8 threads used to upload the files, then there will be 2 .bak files uploaded to the backup destination.

Another example, if there are 10 files this time with the same file size of 15 MB each. Then there will be 8 .bak files uploaded to the backup destination. The files will be combined like this:

ThreadsFilename
Thread 1: File 1 and File 9 (30MB)000000.bak
Thread 2: File 2 and File 10 (30MB)000001.bak
Thread 3: File 3 (15MB)000002.bak
Thread 4: File 4 (15MB)000003.bak
Thread 5: File 5 (15MB)000004.bak
Thread 6: File 6 (15MB)000005.bak
Thread 7: File 7 (15MB)000006.bak
Thread 8: File 8 (15MB)000007.bak

For illustration purposes, the following example are with Deduplication OFF and Compression OFF. If the source contains 45 files to backup (each 15 MB in size) and some small text files of a few KB each; then for the first backup there will be 16 .bak files uploaded to the backup destination. Those files will be combined like this:

ThreadsBlock FilenameFile
Thread 1000000.bak, 000008.bakFile 1, File 9, File 17, File 25, File 32, File 39
Thread 2000001.bak, 000009.bakFile 2, File 10, File 18, File 26, File 33, File 40
Thread 3000002.bak, 00000a.bakFile 3, File 11, File 19, File 27, File 34, File 41
Thread 4000003.bak, 00000b.bakFile 4, File 12, File 20, File 28, File 35, File 42
Thread 5000004.bak, 00000c.bakFile 5, File 13, File 21, File 29, File 36, File 43
Thread 6000005.bak, 00000d.bakFile 6, File 14, File 22, File 30, File 37, File 44
Thread 7000006.bak, 00000e.bakFile 7, File 15, File 23, File 31, File 38, File 45
Thread 8000007.bak, 00000f.bakFile 8, File 16, File 24, small text files

While for large single source files, the .bak files will be like this for:

FileBlock Filename
90 MB file000000.bak ➝ 63 MB
000000.000001.bak ➝ 27 MB
266 MB file000000.bak ➝ 63 MB
000000.000001.bak ➝ 63 MB
000000.000002.bak ➝ 63 MB
000000.000003.bak ➝ 63 MB
000000.000004.bak ➝ 63 MB