Support Center

Backup/ Restore Capabilities

Last Updated: May 05, 2018 11:05PM PDT
This article describes :Recover capabilities as an introduction to Restore and Rebuild, and includes links to additional articles for specifics.

With the prevalence of Ransomware and internal sabotage, it is no longer sufficient to operate without reliable backup/ restore. With :Recover, you maintain access to (often the most recent) versions each file you create, protect, and subsequently access. Unlike other backup/ restore solutions that periodically copy data from your host to another location, SSProtect retains protected content each time you make changes, with zero procedural impact: Backup is policy-driven while Restore (Rebuild) is either user-driven or automated with programmatic APIs.

:Recover and Patented KODiAC Protection
 utilizes Double Encryption rather than Optimized Offloading, as described in the article, Operating Modes. Note that both modes provide protection against ISP access to your plaintext content, and also protect against one-sided legal action that recovers ISP decryption keys - alone insufficient for plaintext access.

For both operating modes, KODiAC (Cloud) Services generates and isolates/ manages decryption keys that are alone insufficient to access your content. These keys must be combined with decryption keys generated by and (securely) managed on your host computer. These keys, and your protected ciphertext content, are not present in the same place until after you make an authorized request to access plaintext. Authorization optionally utilizes two-factor authentication as a prerequisite, and this is built into the patented protection mechanism to provide additional protection against attackers using stolen credentials (network administrator passwords, for example).

Performance Impact
Double Encryption requires two decrypt operations for plaintext access, and both are carried out on your host computer. This minimizes transfer latency without sacrificing security.

In fact, the more time-consuming re-encryption operation is carried out only after you close a data file and move on to other tasks, allowing operation to continue in the background. The impact to concurrent computing tasks is minor, though directly related to host computing capability.

Dynamic Mode Switching
To support optimized performance, you can configure a threshold data size that triggers a prompt for dynamically switching from Double-Encrypted operation to Optimized Offloading (which precludes access to backup data), though often the time it takes to acknowledge the prompt is sufficient to re-encrypt typical business data files. Adjust this for your host's computing power, :Recover Quota limits, and data retention needs.

If this limit is smaller than any protected file you save and close, the mechanism is actively, operating either automatically or by prompting you to decide which mode of operation you wish to use. Though this option is not available in any User Interface display as of version 7.1.x, the upcoming v7.2 series of releases will allow you to make changes in the UI alongside the dynamic switching mechanism's controls (bypassing the need to modify Registry settings).

For information on configuring these features, refer to the article, Using :Recover.

Restoration Reliability
The Restoration process is as close to assured as possible, given data access operation uses the exact same procedure as that associated with a data Restore/ Rebuild operation - except that Restore/ Rebuild doesn't perform actual decryption until you make the request. Authentication requirements do not change in any way, specifically managed by Policy associated with your Account (and/ or governing Organization).

Restore/ Rebuild Name Conflicts
When you Restore (or Rebuild) a file to a target that already exists, unless you have chosen to automatically overwrite using the UI option checkbox, you will be prompted to Skip the operation or Replace the target. If you choose Replace, the two files are compared before the older of the two is renamed with a 3-digit extension. This way, both files remain for further review, with the latest taking the native filename's place.

The use of the 3-digit extension is repeated for subsequent operations, for example if you later perform the same operation or perform a multi-select Restore/ Rebuild operation that results in more than one file targeting the same destination. In each iteration, the latest file is retained in the native target's location while alternate instances takes the next increasing numbered extension available (i.e. .000, .001, .002, etc). As of release v7.1.x, these files remain until you remove them manually (in protected, Double Encrypted form retaining all managing access Policies).

Foundation for :xRecovery Disaster Recovery
 content cannot be intentionally removed (see below) except after a multi-phase Administrative Account Delete and Seat Recovery operation. As a result, managed versions of protected :Recover content is available for :xRecovery Archive re-creation, which provides secure offline access for Disaster Recovery. For more information, refer to, Abbreviated Procedures for :xRecovery.

Remote Profile Deployment
support relocation of a Profile to a new Host computer, as described in the article, Remote Profile Deployment. When combined with :Recover Rebuild operation, you can easily recreate an SSProtect secure data management environment in response to host corruption, compromise, sabotage, theft, device loss, destruction, or other circumstances that render host computing resources unusable.

Limiting Multiple Instances of a Single Item
By default, :Recover operation only seeks to retain the last 3 instances of a managed item, allowing older versioned instances to be removed to retain Quota space for the addition of new data items. Of course, so long as there is available Quota space, older versions will be retained. In fact, these older instances are only removed when the Quota is full and a request for a new item is submitted.

This can be disabled if you wish to keep every instance of every file ever managed by your Account, or those in your Organization. Refer to, Archives and Quotas, for details.

Restore vs. Rebuild
Restore is intended for use on an existing host, since the operation intends to place Restored content in its' native path. When the native path does not exist, the target file is placed in the Overflow Folder.

Rebuild is instead intended for Remote Profile Deployment on different (new) hosts. As such, Rebuild creates target paths when they don't exist (and when possible). As a fallback (in some cases), the path is re-created in the Overflow Folder (vs. storing the file directly in the folder). This facilitates recreation of similar structural relationships once content is available on the target computer.

For details, refer to the article, Restoring and Rebuilding.

For More Information
For information regarding product features and content, consult the Document Index, or send email with specific questions to


This article was updated w/ v7.1.1 of the :Foundation Client

Contact Us
seconds ago
a minute ago
minutes ago
an hour ago
hours ago
a day ago
days ago
Invalid characters found