This article explains :Recover Archives, Quotas, Retention Policies and associated configuration.
:Recover is an optional SSProtect service component that delivers high availability of managed content. Individual versions of managed items are made available for Restoration at any time using any one of several methods described in the article, Using :Recover.
Content is stored in the KODiAC Cloud Archive and limited by Storage Quota associated with both an Organization and an individual Account.
Organization Administrators and Delegates enable/ disable :Recover for Organization Accounts using the Administer Users display available from the notification icon's menu:
:Recover Quota is applied to an Organization as a whole, and configurable from within this same Administer Users display. In the above example, the Organization Quota is 2.5 GB, with the current Account allocating 2200 MB for storage. This value can be changed by selecting the target Account, choosing Edit (matching the state shown above), modifying AcctQuota, then choosing Save. Be sure :Recover is checked, which activates the service for the target Account (since the Quota is always present and can always be changed).
Note that OrgAvail currently shows how much more space the Organization has for available assignment - in the above example, 300 MB more than the 2200 MB configured when choosing Edit. As such, the managing Privileged User could in this case enter 2500 to assign all available space to the target Account, leaving nothing for future/ new Accounts. This can of course be modified at any time, which allows you to redistribute Quota assignments as you see fit.
To request additional Organization Quota space, send email to email@example.com.
Individual Account Quota
Quota manipulation is slightly different for Individual (non-Organization) Accounts, and its' value is available in the Account Configuration display, also available from the notification icon's context menu. Changes cannot be made from this interface.
Every Account is assigned a default Quota when it is created, regardless of whether or not :Recover is enabled and/ or activated. This provides a starting point with which to work, and it can be changed at any time - even if not active for the target Account (except for Individual Accounts, which require Support requests for changes, as noted above).
SSProtect stores additional data associated with system state and user behavior, which does not affect Account Quota - only managed file content accrues Quota storage space.
Managing Server Content
The KODiAC Cloud Archive cannot be modified; it is strictly used to store/ source Restore, Replicate, Deploy, and :xRecovery operations. Files that are converted (protected/encrypted) get stored in the Archive (when :Recover is enabled for the managing Account) until the Account Quota is met and/ or until removed by Retention Policy, discussed below.
:xRecovery is an additional, optional system service that provides Disaster Recovery services using the KODiAC Archive. :xRecovery allows Privileged Account holders to securely request, acquire, store, and access complete Archive sets using offline computing resources. Content can be acquired for and Individual Account, an Organization Account, or an entire Organization and delivered using a variety of existing cloud data delivery services. For more information, refer to the articles in the :xRecovery Section of these pages.
When the Quota is Exhausted
In general, when using Double or Hybrid Conversion and converting a file that would end up storing more data in the Archive than allowed by the Account's Quota configuration*, the target file is converted using Optimized Offloading (which does not store content in the KODiAC Archive) and the managing User receives system tray notification. Further insight is recorded in the Host Debug Log, and Organization Administrators receive email notification the first time this occurs (after configuration changes to the associated Quota).
In some cases, fallback to Optimized Offloading is not possible, for example when original file size claims observed early in the Conversion process do not end up matching the resulting content size. This latter recognition happens at a stage too late for fallback to Optimized Offloading, and as a result Conversion will instead fail.
Note that Account Quota is only exhausted after optional Retention Policy proceedings are unable to free enough space for the new item, if/ when active. See below for details.
Retention Policy is an optional :Recover capability that implements a method for retaining a minimal number of Archive-stored Versions of each managed data Item before, "removing" older content to make room for incoming data.
Refer to the end of this document for information on, "removal".
Retention Policy configuration is specific to each Organization (or Individual Account) and specifies the number of most-recent Versions of a managed Item that MUST be maintained (and available) in the KODiAC Archive.
Retention Policy Execution
Retention Policy execution is logically simple, though reality offers results that can be difficult to evaluate. This is due to implementation that honors stringent cryptographic cloud offloading performance, the security of ensuring incoming Item size claims matches the amount of content delivered for KODiAC Archive retention, and more significantly, changes to the configured minimum number of Item Versions for Retention.
In summary, Retention Policy uses early-stage Conversion size claims to incrementally remove old content until enough space is available for the claim. As previously noted, this size claim may differ from the actual content uploaded during late stages of Conversion (cryptographic offloading), and as a result free space may not be sufficient for the resulting content. This leads to Archive Storage failure and in this particular instance does NOT revert back to Optimized Offloading for Item management - Conversion will fail.
This is not common, but not impossible - and an important caveat. Size claims are secured, but not impossible to corrupt given they are a part of a potentially compromised host. The tradeoff between risk and performance warrants the use of this approach to maintain scalable usability without adverse impact to the reality of managing content.
NOTE: When Retention Policy is disabled, Conversion failure most often results in fallback to Optimized Offloading. If/ when initial size claims transcend the available free space left by Quota configuration values, Conversion fails - even if the resulting size would be small enough to fit in remaining space.
Retention Policy :Recover Restore Indication
When Items are removed from the KODiAC Archive, they are no longer available for Restore operation from the Managed Files/ Restore interface. This can be seen when enumerating File Versions for any specific Item, with "Y" indicating available content, and, "-" indicating that content is not available for manual Restoration. For more information, refer to, Managing Host Data and this section's article, Managing Archive Data.
Retention Policy Audit Records
Retention Policy removal activity is securely recorded in associated File Event Audit records and made available in File Detail Reports. This activity is recorded as a Quota Limit operation just before associated file conversion sequence details. In the (abbreviated) Report example below, version 3 of the same file being converted (protected/encrypted) was removed to make space:
For clarity, it's worth noting that, in this case, Retention Policy for the associated Organization would have to be 1 or 2 minimum retained Item Versions.
Retention Policy Removal Priority
Retention Policy always removes the oldest (candidate) Version instances first, scoped to the calling Account's Organization. This can result in the removal of one or more individual Versions of a single Item (file), one or more Versions of multiple Items, and/ or multiple Versions of multiple Items spread across multiple Organization Accounts.
Retention Policy Removal
It's important to note that, "removal" does not mean content is erased from the KODiAC Archive - it is in fact moved to Cold Storage. Cold Storage items are not available for manual Restoration, as noted above, and are not globally replicated. This data is also not currently included in :xRecovery offline Disaster Recovery Archives.
If you have a need to gain access to this content before we add it as an optional aspect of :xRecovery, submit a request to Support so we can work together to meet your needs.
Viewing Retention Policy Configuration
Privileged Users and Individual Account holders can view the Retain Versions setting from Administer Users and Account Configuration, respectively. To request a change to this value, submit a request to Support.
:Email is fairly complex and specific to integration with Microsoft Outlook. Use Policies to control default behaviors - more information will be available in related articles.
In the meantime, you can search this site for more information on various topics, or use this link to submit a specific request. You can also send email directly to firstname.lastname@example.org, and our staff will respond to your needs as soon as possible.
In the meantime, don't forget to check out our primary website and Insights columns for information on current trends, security topics, and how our technologies relate.
This article was updated w/ v9.3.2 of the :Foundation Client