Close menu

Realtime Scanner

 Scanner in Real Time
The Realtime Scanner is an engine that is intimately connected to the AppServer that intercepts all transactions that occur on each user mailbox and records them in order to save the whole history of an item for its entire existence.
 
The Realtime Scanner allows you to recover any object at any moment in time.
 
The Realtime Scanner reads all AppServer events in near real-time, then repeats the same activities on its own data structure, producing objects or modifying their information. Because no data is ever overwritten in the backup, each object has its own entire history.

Enable the Realtime Scanner

Set the ZxBackup_RealTimeScanner property to TRUE.

zextras$ carbonio config set server $(zmhostname) ZxBackup_RealTimeScanner TRUE

Disable the Realtime Scanner

Set the ZxBackup_RealTimeScanner property to FALSE.

zextras$ carbonio config set server $(zmhostname) ZxBackup_RealTimeScanner FALSE

When Should the Realtime Scanner Be Disabled?

The only time you should disable the Realtime Scanner is while performing an ref:external_restore of multiple domains. This is a safety measure to avoid high load on your server. After the import, re-enable the Realtime Scanner and perform a SmartScan when prompted.

Limitations and a Safety Check
When recovering data gathered with the Realtime Scanner, the biggest limitation is when the user utilises the Empty Folder button in the right-click context menu.
 
When Carbonio Backup cannot establish the state of an item in an account by reading the information stored by the Realtime Scanner in this situation, a Smartscan on the provided account is performed before the restore: this operation repairs any misaligned data and sanitises the backed up metadata.
Backup Mode Without Blobs
Carbonio’s Blobless Backup Mode avoids saving up item blobs while still protecting all other item-related data.
 
This mode is intended to take use of the storage solution’s advanced storage features, such as built-in backup or data replication, by optimising both the backup module’s disc space utilisation and recovery performance.
 
There is only one prerequisite for enabling Blobless Backup Mode.
 
  1. There must be no independent third-party volumes: Blobless Backup Mode only works with local and centralised third-party volumes.
 
Blobless Backup Mode is storage-independent and may be activated on any server or infrastructure that fulfils the aforementioned requirements, regardless of storage provider.
Blobless Backup Mode works exactly like its default counterpart: the RealTime Scanner handles item changes while the SmartScan handles domain/COS/account consistency; the only difference is that in Blobless Backup Mode, the backup contains no items of type blob  while still saving all metadata and transaction history.
 
It is critical to remember that when Blobless Backup Mode is activated, it impacts the whole server and no blobs are backed up regardless of the target volume or HSM settings.

Warning

When the backup is set to Blobless Mode, BLOBs will not be deleted until those are out of the retention period.

Blobless Backup Mode is a CLI-only feature that may be activated or removed with the backup command.To activate the BloblessMode configuration property at the global and server levels, for example:

zextras$ carbonio config global set attribute backupBloblessMode value true

Alternatively, to activate it solely for the domain mail.example.com:

zextras$ carbonio config server set mail.example.com attribute backupBloblessMode value true
Backup purging 
Backup Purge is a cleanup action that removes from the Backup Path any deleted item that exceeds the Retention Policy’s retention time.
 
The Purge engine checks the information of all removed items and deletes any objects marked for deletion whose last update is older than the retention time range.
 
However, if the blob of an item is still referenced by one or more valid metadata files, the blob will not be erased owing to Carbonio Backup’s built-in deduplication.
 
Backup purging may be done manually through the CLI or scheduled using the Admin Panel (Admin Panel +‣ Global Server Settings ‣ Server Config).
 
However, if infinite retention is enabled (i.e., the Data Retention Policy is set to 0), the Backup Purge will end instantly since no removed item will ever surpass the retention duration.

Run a Backup Purge

To start a Backup Purge run the command

zextras$ carbonio backup doPurge [param VALUE[,VALUE]]

Check the Status of a Running Backup Purge

To check the status of a running Purge run the command

zextras$ carbonio backup monitor *operation_uuid* [param VALUE[,VALUE]]
Backup Limitations and Special Cases
There are a few instances where the backup does not function properly. These cases are discussed in this section.
 
  1. The newest state available should NOT be used to restore an active account on a new account. Assume that a person deletes all of his emails by accident, or that the emails in an account are lost for whatever cause (for example, a server failure). The user requests their return and approaches the administrator. If the admin restores the account’s status to the most recent accessible state, the new account will include the most recent available state, which is an empty account, because the email was previously erased in the most recent state. As a result, in order to successfully recover the account, it must be restored at a period in time before the emails were deleted.
  2. If the email client is configured to download email messages and delete them immediately from the server while utilising the POP3/POP3S protocol, these messages may not be included in the backup. If the Carbonio Storages component is installed, this does not occur.
  3. When an email is sent directly over an SMTP connection (e.g., using a multifunctional device or connecting to the STMP server through telnet), it is not included in the backup.
  4. When using an IMAP/SMTP client to send email, the IMAP client must be set to store the send email in a remote folder (through the IMAP STORE command) after the send operation, or the email may not be included in the backup.

Note

The last two cases do not apply when using a browser to connect to the AppServer. In this case is it the AppServer that contacts the SMTP server to send the email and automatically passes the email to mailboxd.