Support Center

Restoring and Replicating

Last Updated: Jun 15, 2019 09:47PM PDT
This article shows you how to Restore and Replicate managed content.

Managed Files/ Restore (:Confidential Files)
When :Recover is available to your Organization and specifically enabled for your Account, you can access Archive content as described in this article. For configuration details, refer to the article, Using :Recover.

NOTE: If/ when :Recover is temporarily disabled for your Account, you will not be able to Restore/ Replicate Archive content.

Accessing Restore/ Rebuild
Navigate to the Managed Files/ Restore display using the notification panel's context menu item of the same name. When using :Recover, you can Restore content from the Hostlist, Versionlist, or Archivelist Panels (though Replicate is only available from the Archivelist):

General Restore/ Rebuild Operation
Select one (or more) files from any of the UI Panels, then choose RestoreSSProtect will loop through each selected item and attempt to acquire the latest Version from the KODiAC (Cloud) Archive and place results in the last-used target location. In this example,
Open Calls.xlsx will be placed in the C:\SupportDocs folder.

If the target folder does not exist, the file is placed in the Overflow Folder, which in this case happens to match the native destination. Success utilizes INFO notification text in Host Debug Logs, while failure is reflected with ERROR entries.

If you are not configured for INFO level logging, check the Log Restore option. This automatically includes INFO Restore entries without affecting your log settings.

Restoring Versioned Instances
When you Restore a Versioned Instance from the Versionlist Panel, the resulting file reflects the individual Version you selected from the list (you can select more than one here as well). As such, the target filename will be
<filename>-vx.<ext>, where x reflects the Version instance for each selected item.

Restore (and Replicate) operations, in all other cases, use the native Filename shown in the UI.

Archive Instances Used for Restore/ Rebuild
For each file, when you Restore from the Hostlist or Archivelist, the latest available Version instance is used. Availability is restricted to items present in the KODiAC Archive and also those to which you have peer sharing access, which depends on the Conversion Operating Mode. Rules are enumerated at the end of this article.

Date/ Time Information
retains Versioned instance date/ time information in the resulting file. Times are mapped to the local timezone (though displayed in UTC/ GMT time). This allows you to retain visibility into secured, managed access over time, despite moving content from one host to another. This also facilitates name collision processing, as described below.

Prompts for File Conflicts
If a target file already exists in local storage, you will be prompted to Replace the target file or Skip the given instance:

Choose Apply to remaining cases if you wish to use the same answer for any future conflict (in the present multi-select operation), then click Replace or Skip.

Replacing Existing Files
Once SSProtect has been instructed to overwrite existing content, the pending Archive instance is compared with the existing instance to determine which of the two is more recent. The older file is renamed to
<filename>.<ext>.000, and the newer file replaces the target <filename>.<ext>. If/ when <filename>.<ext>.000 exists, SSProtect increments the counter until an appropriate target filename is found.

As such, after a multi-select Restore/ Replicate operation, you can review the target file and associated numbered instances to retain items of interest and delete unnecessary content (as all files are Restore to protected Ciphertext format).

NOTE: Though the final target file will not be different, multi-select specifics change the order in which content is processed. This is reflected by the sorting you use and resulting multi-select scope. Operation begins with the top item in the selected set, then proceeds downward through the selection set, in order. If you change the sort order and choose the same set of files, then repeat the operation (with a clean set of target folders), interim file content that uses numbered extensions (noted above) will not be ordered the same way.

Replicate vs. Restore
Rebuild seeks to re-create a file's native folder structure inside your Overflow Folder, whereas Restore attempts to utilize an existing (matching) path. In some cases, however, Restore cannot recreate the necessary target folder(s), for example when Archive content comes from a
D:\ volume that does not exist on the current Host. In this case, Restore operates like Replicate by creating the folder structure inside the Overflow Folder. This allows you to Restore/ Replicate content then reposition entire portions of the result for ongoing localhost use.

Remote Deployment and :Expand -rebuild
supports Remote Profile Deployment with the
-deploy command. Use the optional -rebuild switch to initiate an Archive Replicate operation that supplements automated deployment.

Refer to the article, Remote Profile Deployment, for more information.

Restore/ Replicate Versioned Access Rules
As previously noted, Restore/ Replicate finds the most recent qualified Version of a file to recall from the KODiAC Archive. In some instances, legitimate, stored content is not acquired simply because you will not be able to access it. This is obviously the reality when content is not available (i.e. Size=0) due to the use of Optimized Offloading (purposed or as a result of failure fallback) or  Retention Policy removal. It is also the reality in certain circumstances based on the Conversion Mode being utilized. Access rules are as follows:

    Accessible - Double Conversion from an Organization Peer
    Accessible - Double Conversion from a Third Party Trust
    Accessible - Hybrid Conversion from an Organization Peer
    Not Accessible - Hybrid Conversion from a Third Party Trust
    Not Accessible - Optimized Offloading (Size=0), from Any User

The Conversion Mode is managed by the, "owner", i.e. the Account that creates Version 1 of any managed file. Sharing peer settings never impact the way in which managed content is Converted - though of course changes to Account settings allow you as the, "owner" to impact the progressive use of different Operating Modes. Sharing peers default to the Conversion scheme associated with the last instance in the Version Chain that you created (saved/ closed).

You can verify the, "owner" of a given Version Chain by navigating to the Versionlist and scrolling down to the Version 1 instance to lookup the associated Username. As of v9.3.2, you should never find an item that holds a Version 1 instance with a Username different from your own. This is by design and specific to the requirement that :Recover Restore/ Replicate functionality limit access to content stored in your KODiAC Archive (and thus accruing storage space against your Quota).

Finally, :xRecovery may scope data differently, depending on the KODiAC instance deployed in your default Server Set. For more information, refer to :xRecovery Topic articles.

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/ v9.3.2 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