The Disaster
What may go wrong
One or more of the following events must take place for a situation to be labelled as a disaster:
- One or more critical filesystems (such as / or /opt/zimbra/) experiencing hardware failure
- a crucial filesystem’s contents rendered useless by internal or external forces (such as a thoughtless rm * or an incursion from outside)
- Hardware malfunction of the virtualization infrastructure or the actual computer hosting the Zimbra service
- a serious issue with a software update or OS upgrade
reducing the likelihood
Here are some ideas to reduce the likelihood of a catastrophe:
- Always preserve important filesystems on distinct discs, such as your Zextras Backup Path or /opt/zimbra.
- For your server, use a monitoring and alerting solution to spot issues as soon as they arise.
- Plan your upgrades and migrations thoroughly.
How to Recover Your System: The Recovery
There are two steps in the recovery of a system:
- Base system recovery (installing and configuring the OS, installing and configuring Zimbra)
- Data recovery (reimportation of the most recent data, including user and domain setups, COS data, and mailbox contents)
What role does Zextras Backup play in recovery?
Zextras Backup’s Import Backup tool offers a quick and secure solution to carry out step 2 of a recovery.
You can restore a fundamental installation of Zimbra to the last working state of your previous server by using the backup path of the old server as the import path.
The Rehabilitation Process
- Install Zimbra on a fresh server, then set up the global and server settings.
- the new server with Zextras Suite installed.
- Mount the old server’s backup folder on the new one. Use the most recent version of either of the two external backups if this is not an option.
- Use the CLI command below to start an External Restore on the new server:
- The system will be available for your users as soon as the External Restore procedure is finished (see your Zextras Suite Notifications), since it will instantly generate the domains, accounts, and distribution lists. Emails and other mailbox contents will thereafter be recovered.
Configurations and Setting
Although server and global settings are backed up, they are not immediately restored. With the exception of the minimum Zimbra version necessary to operate Zextras Suite, Zextras Backup’s high-level integration with Zimbra enables you to restore your data to a server with a different operating system, a different Zimbra release, a different networking configuration, and a different storage setup.
Zextras Backup has a very helpful CLI function that may be used whether you want to make an exact replica of the previous server or only use it to change its settings to a new environment.
Snapshots and VMs
Virtual machines are presently the most popular option to install server solutions, such as Zimbra Collaboration Suite. This is due to the introduction of highly developed virtualization technologies in recent years.
The majority of hypervisors offer programmable snapshot features and snapshot-based VM backup solutions. Using Zextras Backup’s External Restore function and the server’s backup path as the import path, it is always feasible to roll back to the most recent snapshot in the event of a disaster and recover the lost data.
Recovery from a Disaster from a Previous VM State
You can preserve a frozen duplicate of a virtual machine in a usable condition and roll back to it whenever you want with snapshot-based backup methods. It’s preferable to make snapshot copies of powered-off VMs, however this is not required to completely guarantee data consistency.
With Zextras Backup, you may do a catastrophe recovery from a prior machine state by:
- Make sure that no users can access it and that neither incoming nor outgoing emails are sent before you restore the most recent backup onto a different (clone) VM in a separate network.
- Turn on the copy, then wait for Zimbra to launch.
- Disable the RealTime Scanner for Zextras Backup.
- Connect and mount (on a separate path) the virtual disc holding the unaltered backup path to the clone.
- Launch an external restore while utilising the import path for the backup.
By doing this, the disaster recovery process will be sped up as all objects in the Backup Path will be parsed and the missing ones imported. As long as user access and mail traffic are restricted, these processes can be performed as many times as necessary.
Verify that everything is operational when the restoration is finished, then restart user access and mail traffic.
The Fallout: What Comes Next?
Simply initialise a new Backup Path and store the old one in case you need to recover any stuff from before the disaster.
Unrecoverable Items
How can I be sure that every one of my products has been replaced?
It’s quite simple. Once the restoration procedure was complete, look at the relevant procedure Completed notification you got. It is also emailed to the address you set in the Core part of the Administration Zimlet as the Notification E-Mail recipient address. It may be seen in the Notifications area of the Administration Zimlet.
The skipped items section includes a list of unrestored things for each account, as demonstrated by the following excerpt:
Comparison of skipped and unrestored items
omitted thing
An object that has previously undergone restoration, either recently or in the past.
untouched object
a thing that wasn’t restored because the restore procedure ran into trouble.
Why hasn’t everything I own been restored?
There are several potential reasons, the most prevalent of which are as follows:
Click Error
A permissions problem or an I/O fault prevents reading of the raw item or the metadata file, respectively.
Broken thing
Both the the raw item or the metadata file are readable by Zextras Backup but their content is broken/corrupted.
faulty item
The content is accurate and can be read in both the raw item and the metadata file, but Zimbra won’t inject it.
How Can I Tell If Something Isn’t Restored?
Both the CLI and the Zimbra Web Client may be used to do this. The backup/import path may be searched for the item using the first method, and the source server can be seen using the second method.
How Can Unrestored Items Be Restored?
An item that cannot be restored clearly indicates that there is a problem, either with the item itself or with your present Zimbra configuration. In some circumstances, even if an item cannot be restored on the first try, there are still strong odds that it can be recovered.
You can find a number of useful hints and pointers in the paragraphs that follow for handling various sorts of irreparable objects.
Items that were not restored due to a read error
It is necessary to make a careful distinction about read faults that may prevent objects from being restored:
Hardware malfunctions and all other destructive mistakes that result in irrecoverable data loss are considered hard errors.
Soft mistakes
non-destructive mistakes, such as incorrect permissions, filesystem faults, RAID problems (such as faulty RAID1 mirroring), etc.
While there isn’t much you can do to prevent or reduce hard mistakes, you can do so by adhering to the following rules:
- Verify the filesystem.
- Depending on the RAID level, inspect the array for any potential problems if employing a RAID disc system.
- Verify that the backup/import path, all of its subfolders, and any files within included are accessible to the ‘zimbra’ user with r/w access.
- Examine the network-shared filesystems’ links with care. Consider using rsync to transmit the data if the network quality is bad.
- Make careful to run the mount command as root with the -o allow_other option if you’re using SSHfs to remotely mount the backup/import path.
Items that were found to be broken were not restored.
Unfortunately, in terms of salvageability, this is the poorest category of unrestored objects.
Depending on how corrupted the item is, it could be feasible to restore either its original state or the raw object (emails are the sole exception). Utilise the getItem CLI command to determine the level of corruption:
The procedures listed below will enable you to recover a typical.eml file if the item is an email:
- Find the most recent legal state.
- Consider the following from the aforementioned snippet:
- Determine the blob’s route.
- Take the blob’s previous step’s path:
- Uncompress the BLOB file into an.eml file using gzip and you’re done! Now, using your preferred client, import the.eml file into the relevant mailbox.
Items that were determined to be invalid were not restored.
Despite being legally accurate, a piece of content is labelled as invalid when Zimbra’s LMTP Validator rejects it after injection. Validation criteria are often altered, thus not all messages that were considered legitimate by one version of Zimbra are still considered valid by a subsequent version. This is typical when importing items produced on an earlier version of Zimbra to a current one.
- It could be a good idea to temporarily stop the LMTP validator and redo the import if you encountered a large number of unrestored items during the import:
- Run the following command as the Zimbra user to deactivate the LMTP Validator in Zimbra:
- You may activate the LMTP validator when the import is finished by executing:
Who Watches the Watchmen? Taking Additional and Offsite Backups of Zextras Backup’s Datastore
Having backup systems is a fantastic way to protect against data loss, but in order to guarantee the maximum degree of dependability, each backup system has to be a part of a larger backup plan. Lack of a sound backup plan might make one feel secure while really putting even the strongest backup systems in the world at risk of failing again.
Making a backup plan is not a simple task, and you will eventually have to consider the following scenario: “What if I lose the data I backed up?”. In the end, the likelihood of this occurring only depends on how you create and maintain your backups. For instance, storing both your data and backups on the same SATA-II disc increases the likelihood that you will lose all of your backup data compared to storing your backups on a separate SAN using a RAID 1+0 configuration.
Creating a copy of the copy NG datastore and storing it offsite is one of the greatest ways to improve your backup plan, as are the following recommendations and best practises.
Making a Second Backup of the Datastore for Zextras Backup
A backup can make use of the well-known database qualities known as ACID, which ensure data validity and integrity, to reduce the likelihood of data loss.
It is relatively simple to create a backup of the Datastore and ensure the authenticity and integrity of the material by adhering to these principles. Using the rsync programme, which is built around a method that only transmits deltas (i.e., what really changed) instead of the entire data and operates progressively, is the best (and simplest) way to achieve this. A connection to an rsync daemon rather than utilising a remote shell as a transport is often more faster at moving the data than the latter. Specific settings and parameters depend on a variety of circumstances, including the volume of data to be synchronised and the storage being used.
To create an additional backup of the datastore for Zextras Backup using rsync, you won’t have to stop Zimbra or the Real Time Scanner, and because of the ACID features, you can always pause the sync and resume it at a later time.
Offsite Storage of Your Zextras Backup’s Datastore Backup
As was seen in the previous section, it is quite simple to create a backup of Zextras Backup’s Datastore, and using rsync to store your backup in a remote place is just as simple.
The following best practises are advised when working with this type of configuration to optimise your backup strategy:
- When scheduling your rsync backups, be careful to provide enough time between each rsync instance so that the transfer can be finished.
- To prevent discrepancies, use the –delete options to ensure that files destroyed on the source server are also deleted on the destination server.
- Schedule two separate rsync instances: one with –delete to be performed after the weekly purge and one without this option if you observe that using this method takes too much time.
- Make sure to start from Zextras Backup’s Backup Path and move the entire folder tree recursively. Mapfiles and server configuration backups are included here.
- Make that the filesystem at the destination respects case, just as Backup NG’s Backup Path must.
- Make sure that the zimbra user on your server has read and write access on the transmitted data if you intend to restore directly from the distant location.
- If your transfer speed is significantly higher than your storage throughput (or vice versa), you should prepare for slowdown.
Command Execution in a Multistore Environment, Zextras Backup in a Multistore Environment, and Multistore Information
The Network Administration Zimlet makes managing several servers easier: Even if you are signed into the Zimbra Administration Console of another server, you may choose a server from the Zextras Backup tab and carry out all backup procedures on that server.
The following specific variations exist between Singlestore and Multistore environments:
- Restore on New Account actions in a multistore system MUST ALWAYS generate the new account on the mailbox server for the Source account.
- On the target server rather than the server that initiated the process, all actions are recorded.
- Zimbra will automatically forward a request for an action to the correct server if the incorrect destination server is selected.
Restore and Backup
In a multistore context, backup and restore functions will be identical to those in a singlestore system.
The Administration Zimlet will be used to configure and administer each server independently, however some actions, such as Live Full Scan and Stop All Operations, may be ‘broadcast’ to all mailstores using the zxsuite CLI. This is done by using the –hostname all_servers option. This holds true for Zextras Backup settings as well.
Operations for backup and restore are controlled as follows:
- On a single server, using the Administration Zimlet, or on a number of servers, using the CLI, smartscans may be run.
- The Accounts tab in the Zimbra Admin Console, the Server tab in the Zextras Backup menu of the Administration Zimlet, or the CLI may all be used to launch restores. These techniques vary in the following ways:
both import and export
When used in a Multistore system, the Export and Import functions are the most dissimilar. These are the standard situations:
The commands doCheckShares and doFixShares
All share data in local accounts will be analysed by the doCheckShares command, which will also indicate any errors:
Using a migration, the doFixShares will correct all share inconsistencies:
The Operation Queue of Zextras Backup and Queue Management
Zextras Backup operations are always enqueued in a dedicated, unprioritized FIFO queue when they are begun, whether manually or by scheduling. As soon as a previous operation is dequeued (either because it has finished or been terminated), the subsequent operation is carried out.
The subsequent operations are impacted by the queuing system:
- outside backup
- Every restoration procedure
- SmartScan
Changes to Zextras Backup’s configuration are implemented right away and are not queued up.
Operating Queue Control
Manage backups at the COS level
What is COS-level Backup Management? COS-level Backup Management enables the administrator to turn OFF ALL Zextras Backup features for an entire Class of Service in order to save storage consumption.
- What Is the Process for COS-level Backup Management?
- What occurs if the Zextras Backup Module is turned off for a Class of Service?
- All accounts in the COS will be disregarded by the Real Time Scanner.
Accounts in the COS WILL NOT BE EXPORTED via the Export Backup procedure.
The backup system will regard accounts in the COS as deleted. This indicates that all data for those accounts will be deleted from the backup repository after the data retention term has passed. This will be reset if the backup for a Class of Service is enabled again.
How is the information about backup enabled/disabled saved?
When a Class of Service’s backup is disabled, the Notes field of that Class of Service gains the following marker: ${ZxBackup_Disabled}
The backup for the COS will now again be available if you change or delete this marker, even though the Notes field is still completely editable and useable.
The Disaster
What may go wrong
One or more of the following events must take place for a situation to be labelled as a disaster:
- One or more critical filesystems (such as / or /opt/zimbra/) experiencing hardware failure
- a crucial filesystem’s contents rendered useless by internal or external forces (such as a thoughtless rm * or an incursion from outside)
- Hardware malfunction of the virtualization infrastructure or the actual computer hosting the Zimbra service
- a serious issue with a software update or OS upgrade
reducing the likelihood
Here are some ideas to reduce the likelihood of a catastrophe:
- Always preserve important filesystems on distinct discs, such as your Zextras Backup Path or /opt/zimbra.
- For your server, use a monitoring and alerting solution to spot issues as soon as they arise.
- Plan your upgrades and migrations thoroughly.
How to Recover Your System: The Recovery
There are two steps in the recovery of a system:
- Base system recovery (installing and configuring the OS, installing and configuring Zimbra)
- Data recovery (reimportation of the most recent data, including user and domain setups, COS data, and mailbox contents)
What role does Zextras Backup play in recovery?
Zextras Backup’s Import Backup tool offers a quick and secure solution to carry out step 2 of a recovery.
You can restore a fundamental installation of Zimbra to the last working state of your previous server by using the backup path of the old server as the import path.
The Rehabilitation Process
- Install Zimbra on a fresh server, then set up the global and server settings.
- the new server with Zextras Suite installed.
- Mount the old server’s backup folder on the new one. Use the most recent version of either of the two external backups if this is not an option.
- Use the CLI command below to start an External Restore on the new server:
- The system will be available for your users as soon as the External Restore procedure is finished (see your Zextras Suite Notifications), since it will instantly generate the domains, accounts, and distribution lists. Emails and other mailbox contents will thereafter be recovered.
Configurations and Setting
Although server and global settings are backed up, they are not immediately restored. With the exception of the minimum Zimbra version necessary to operate Zextras Suite, Zextras Backup’s high-level integration with Zimbra enables you to restore your data to a server with a different operating system, a different Zimbra release, a different networking configuration, and a different storage setup.
Zextras Backup has a very helpful CLI function that may be used whether you want to make an exact replica of the previous server or only use it to change its settings to a new environment.
Snapshots and VMs
Virtual machines are presently the most popular option to install server solutions, such as Zimbra Collaboration Suite. This is due to the introduction of highly developed virtualization technologies in recent years.
The majority of hypervisors offer programmable snapshot features and snapshot-based VM backup solutions. Using Zextras Backup’s External Restore function and the server’s backup path as the import path, it is always feasible to roll back to the most recent snapshot in the event of a disaster and recover the lost data.
Recovery from a Disaster from a Previous VM State
You can preserve a frozen duplicate of a virtual machine in a usable condition and roll back to it whenever you want with snapshot-based backup methods. It’s preferable to make snapshot copies of powered-off VMs, however this is not required to completely guarantee data consistency.
With Zextras Backup, you may do a catastrophe recovery from a prior machine state by:
- Make sure that no users can access it and that neither incoming nor outgoing emails are sent before you restore the most recent backup onto a different (clone) VM in a separate network.
- Turn on the copy, then wait for Zimbra to launch.
- Disable the RealTime Scanner for Zextras Backup.
- Connect and mount (on a separate path) the virtual disc holding the unaltered backup path to the clone.
- Launch an external restore while utilising the import path for the backup.
By doing this, the disaster recovery process will be sped up as all objects in the Backup Path will be parsed and the missing ones imported. As long as user access and mail traffic are restricted, these processes can be performed as many times as necessary.
Verify that everything is operational when the restoration is finished, then restart user access and mail traffic.
The Fallout: What Comes Next?
Simply initialise a new Backup Path and store the old one in case you need to recover any stuff from before the disaster.
Unrecoverable Items
How can I be sure that every one of my products has been replaced?
It’s quite simple. Once the restoration procedure was complete, look at the relevant procedure Completed notification you got. It is also emailed to the address you set in the Core part of the Administration Zimlet as the Notification E-Mail recipient address. It may be seen in the Notifications area of the Administration Zimlet.
The skipped items section includes a list of unrestored things for each account, as demonstrated by the following excerpt:
Comparison of skipped and unrestored items
omitted thing
An object that has previously undergone restoration, either recently or in the past.
untouched object
a thing that wasn’t restored because the restore procedure ran into trouble.
Why hasn’t everything I own been restored?
There are several potential reasons, the most prevalent of which are as follows:
Click Error
A permissions problem or an I/O fault prevents reading of the raw item or the metadata file, respectively.
Broken thing
Both the the raw item or the metadata file are readable by Zextras Backup but their content is broken/corrupted.
faulty item
The content is accurate and can be read in both the raw item and the metadata file, but Zimbra won’t inject it.
How Can I Tell If Something Isn’t Restored?
Both the CLI and the Zimbra Web Client may be used to do this. The backup/import path may be searched for the item using the first method, and the source server can be seen using the second method.
How Can Unrestored Items Be Restored?
An item that cannot be restored clearly indicates that there is a problem, either with the item itself or with your present Zimbra configuration. In some circumstances, even if an item cannot be restored on the first try, there are still strong odds that it can be recovered.
You can find a number of useful hints and pointers in the paragraphs that follow for handling various sorts of irreparable objects.
Items that were not restored due to a read error
It is necessary to make a careful distinction about read faults that may prevent objects from being restored:
Hardware malfunctions and all other destructive mistakes that result in irrecoverable data loss are considered hard errors.
Soft mistakes
non-destructive mistakes, such as incorrect permissions, filesystem faults, RAID problems (such as faulty RAID1 mirroring), etc.
While there isn’t much you can do to prevent or reduce hard mistakes, you can do so by adhering to the following rules:
- Verify the filesystem.
- Depending on the RAID level, inspect the array for any potential problems if employing a RAID disc system.
- Verify that the backup/import path, all of its subfolders, and any files within included are accessible to the ‘zimbra’ user with r/w access.
- Examine the network-shared filesystems’ links with care. Consider using rsync to transmit the data if the network quality is bad.
- Make careful to run the mount command as root with the -o allow_other option if you’re using SSHfs to remotely mount the backup/import path.
Items that were found to be broken were not restored.
Unfortunately, in terms of salvageability, this is the poorest category of unrestored objects.
Depending on how corrupted the item is, it could be feasible to restore either its original state or the raw object (emails are the sole exception). Utilise the getItem CLI command to determine the level of corruption:
The procedures listed below will enable you to recover a typical.eml file if the item is an email:
- Find the most recent legal state.
- Consider the following from the aforementioned snippet:
- Determine the blob’s route.
- Take the blob’s previous step’s path:
- Uncompress the BLOB file into an.eml file using gzip and you’re done! Now, using your preferred client, import the.eml file into the relevant mailbox.
Items that were determined to be invalid were not restored.
Despite being legally accurate, a piece of content is labelled as invalid when Zimbra’s LMTP Validator rejects it after injection. Validation criteria are often altered, thus not all messages that were considered legitimate by one version of Zimbra are still considered valid by a subsequent version. This is typical when importing items produced on an earlier version of Zimbra to a current one.
- It could be a good idea to temporarily stop the LMTP validator and redo the import if you encountered a large number of unrestored items during the import:
- Run the following command as the Zimbra user to deactivate the LMTP Validator in Zimbra:
- You may activate the LMTP validator when the import is finished by executing:
Who Watches the Watchmen? Taking Additional and Offsite Backups of Zextras Backup’s Datastore
Having backup systems is a fantastic way to protect against data loss, but in order to guarantee the maximum degree of dependability, each backup system has to be a part of a larger backup plan. Lack of a sound backup plan might make one feel secure while really putting even the strongest backup systems in the world at risk of failing again.
Making a backup plan is not a simple task, and you will eventually have to consider the following scenario: “What if I lose the data I backed up?”. In the end, the likelihood of this occurring only depends on how you create and maintain your backups. For instance, storing both your data and backups on the same SATA-II disc increases the likelihood that you will lose all of your backup data compared to storing your backups on a separate SAN using a RAID 1+0 configuration.
Creating a copy of the copy NG datastore and storing it offsite is one of the greatest ways to improve your backup plan, as are the following recommendations and best practises.
Making a Second Backup of the Datastore for Zextras Backup
A backup can make use of the well-known database qualities known as ACID, which ensure data validity and integrity, to reduce the likelihood of data loss.
It is relatively simple to create a backup of the Datastore and ensure the authenticity and integrity of the material by adhering to these principles. Using the rsync programme, which is built around a method that only transmits deltas (i.e., what really changed) instead of the entire data and operates progressively, is the best (and simplest) way to achieve this. A connection to an rsync daemon rather than utilising a remote shell as a transport is often more faster at moving the data than the latter. Specific settings and parameters depend on a variety of circumstances, including the volume of data to be synchronised and the storage being used.
To create an additional backup of the datastore for Zextras Backup using rsync, you won’t have to stop Zimbra or the Real Time Scanner, and because of the ACID features, you can always pause the sync and resume it at a later time.
Offsite Storage of Your Zextras Backup’s Datastore Backup
As was seen in the previous section, it is quite simple to create a backup of Zextras Backup’s Datastore, and using rsync to store your backup in a remote place is just as simple.
The following best practises are advised when working with this type of configuration to optimise your backup strategy:
- When scheduling your rsync backups, be careful to provide enough time between each rsync instance so that the transfer can be finished.
- To prevent discrepancies, use the –delete options to ensure that files destroyed on the source server are also deleted on the destination server.
- Schedule two separate rsync instances: one with –delete to be performed after the weekly purge and one without this option if you observe that using this method takes too much time.
- Make sure to start from Zextras Backup’s Backup Path and move the entire folder tree recursively. Mapfiles and server configuration backups are included here.
- Make that the filesystem at the destination respects case, just as Backup NG’s Backup Path must.
- Make sure that the zimbra user on your server has read and write access on the transmitted data if you intend to restore directly from the distant location.
- If your transfer speed is significantly higher than your storage throughput (or vice versa), you should prepare for slowdown.
Command Execution in a Multistore Environment, Zextras Backup in a Multistore Environment, and Multistore Information
The Network Administration Zimlet makes managing several servers easier: Even if you are signed into the Zimbra Administration Console of another server, you may choose a server from the Zextras Backup tab and carry out all backup procedures on that server.
The following specific variations exist between Singlestore and Multistore environments:
- Restore on New Account actions in a multistore system MUST ALWAYS generate the new account on the mailbox server for the Source account.
- On the target server rather than the server that initiated the process, all actions are recorded.
- Zimbra will automatically forward a request for an action to the correct server if the incorrect destination server is selected.
Restore and Backup
In a multistore context, backup and restore functions will be identical to those in a singlestore system.
The Administration Zimlet will be used to configure and administer each server independently, however some actions, such as Live Full Scan and Stop All Operations, may be ‘broadcast’ to all mailstores using the zxsuite CLI. This is done by using the –hostname all_servers option. This holds true for Zextras Backup settings as well.
Operations for backup and restore are controlled as follows:
- On a single server, using the Administration Zimlet, or on a number of servers, using the CLI, smartscans may be run.
- The Accounts tab in the Zimbra Admin Console, the Server tab in the Zextras Backup menu of the Administration Zimlet, or the CLI may all be used to launch restores. These techniques vary in the following ways:
both import and export
When used in a Multistore system, the Export and Import functions are the most dissimilar. These are the standard situations:
The commands doCheckShares and doFixShares
All share data in local accounts will be analysed by the doCheckShares command, which will also indicate any errors:
Using a migration, the doFixShares will correct all share inconsistencies:
The Operation Queue of Zextras Backup and Queue Management
Zextras Backup operations are always enqueued in a dedicated, unprioritized FIFO queue when they are begun, whether manually or by scheduling. As soon as a previous operation is dequeued (either because it has finished or been terminated), the subsequent operation is carried out.
The subsequent operations are impacted by the queuing system:
- outside backup
- Every restoration procedure
- SmartScan
Changes to Zextras Backup’s configuration are implemented right away and are not queued up.
Operating Queue Control
Manage backups at the COS level
What is COS-level Backup Management? COS-level Backup Management enables the administrator to turn OFF ALL Zextras Backup features for an entire Class of Service in order to save storage consumption.
What Is the Process for COS-level Backup Management?
What occurs if the Zextras Backup Module is turned off for a Class of Service?
- All accounts in the COS will be disregarded by the Real Time Scanner.
- Accounts in the COS WILL NOT BE EXPORTED via the Export Backup procedure.
- The backup system will regard accounts in the COS as deleted. This indicates that all data for those accounts will be deleted from the backup repository after the data retention term has passed. This will be reset if the backup for a Class of Service is enabled again.
How is the information about backup enabled/disabled saved?
When a Class of Service’s backup is disabled, the Notes field of that Class of Service gains the following marker: ${ZxBackup_Disabled}
The backup for the COS will now again be available if you change or delete this marker, even though the Notes field is still completely editable and useable.