Introduction

There are several ways to restore data in x360Sync, very different from one another, and each fits its own use case. 

This document is created to help our partners better understand how these tools work, which of them are more suitable for which use cases, and what results to expect from each method. In short:

• Restore files or folders - restores specific files or folders which were deleted and are still available in a share in a "deleted" state (grayed out).
• Rollback - rolls back existing active files in a share to the revisions back in the given time. It restores the previous revisions of active (non-deleted) files. It does nothing with deleted files; these are not included in this process.
• Snapshot - creates a full clone of a given share, either in its current state or at a given time (depending on the option chosen). If the time is chosen, files that were active at that time but got deleted since then will be restored in the snapshot - provided they haven't been wiped out yet.

Restore

This restores specific files or folders that were deleted and are still available in a share in a "deleted" state. 

To see such deleted files (they will be grayed out), you can click "Show Deleted" on the toolbar:

The restore can be initiated by right-clicking on a deleted file or folder and selecting "Restore" as shown:

Or alternatively, it can be started in the context of the currently opened folder by clicking on this button named "Restore Deleted" on the toolbar:

Which will then be followed by a restore parameters dialog:

There you can optionally select the time range of deletion to limit the scope of the restore.

Both methods initiate the same restore functionality. It's important to understand and remember that:

• "Restore Deleted" button is context-aware. When pressed, it will initiate the restore for the objects ONLY inside the current folder on the Web, which you are browsing at the moment, and its subfolders. None of the files or folders on the levels above will be restored.
• "Restore All Files" is a dangerous option and should be used wisely. If your organization has no retention policy in place to auto-erase deleted files, this operation will restore all the files that were deleted in this location, starting from the very beginning of the share's existence! For example, if a share is 12 years old and you are restoring from a top level folder, there might be hundreds of thousands of files deleted over time, and all of these will be restored.
• "Restore Files Deleted Between" option dates are inclusive. When you, for example, select Start Date as "June 12, 2025" and End Date as "June 14, 2025," you will get files and folders restored from the very beginning of June 12 to the very end of June 14. Note that these ranges use the current user's timezone.

Use Cases

Some file or folder was just recently deleted: right-click on it and select "Restore" - that will do nicely, no need to use anything more complex than that.

Some files or folders were deleted, they are located in different folders and there are too many of these to initiate "Restore" from the context menu for these - use the "Restore Deleted" button with the "Restore Files Deleted Between" option.

• If you know the location of deleted data (the folder it was in), initiate the "Restore Deleted" from inside this folder - this will greatly reduce the process complexity, and the restore will be way faster.
• If the number of folders involved is small, prefer launching this process from inside each of them individually.
• Try to avoid launching "Restore Deleted" from the very root of the share as much as possible, as the complexity of share-wide restoration is typically very high, and the process can be prohibitively slow when the share has a lot of files and folders. 
• Before moving on with launching the restore, absolutely check the Activity Log to determine when these were actually deleted and set the date range accordingly. End users are often incorrect in their assumptions about the deletion time, and you can easily miss the actual deletion window, which makes the whole process pointless. Try to determine the restoration range as precisely as possible and don't include excess dates; this will make the restoration process way faster.

If you're having some drastic deletion event, like an angry employee deleting the whole share contents, always consider the Snapshot option first. If there are hundreds of thousands of files involved and you launch "Restore Deleted" from the very root of the share, the complexity of this process is expected to be high, and it might take a significant time to complete. Also note that as x360Sync Clients work in real-time, all of these will receive the deletion events, then they will take time to execute these, and then later, when files are restored, they will re-download all of these again. In some cases, when there are hundreds of thousands of files involved, this might cause a significant slowdown in the Clients functioning, and they will take some time to sort it out, which possibly interferes with users' daily activities. Also note that active Clients syncing on a share that's undergoing a big restore job might slow the restoration process down.

If you use the Snapshot option instead, this will allow you to quickly make a full copy of the share at the point in time when deletion hasn't yet occurred. After that you will unsubscribe Clients from the initial share and subscribe them to this new share and make things work in the shortest possible time. Then you will have some breathing room to sort things out in the initial share where deletions have happened, without having an active emergency on your hands and unhappy end users on your back.

Rollback

This feature rolls back all the existing active files in the share to some revisions back in the given time. 

It can be started share-wide by clicking on this button named "Rollback" on the toolbar:

Which will then be followed by a rollback parameters dialog where you could choose the date to roll back:

Important things to understand and remember about this functionality:

• It doesn't restore any deleted files at all. This functionality is not for deleted files.
• This one is NOT context-aware. It always will work for the whole share and all active files.
• It will not be able to restore files to previous revisions if there are none of these. So make sure to keep the "Erase revisions for files unchanged in" setting in org policies big enough so you will have something to roll back to when needed.

How it works: for every file on the share, when the file is updated or edited, we create a new revision. Older revisions are pushed back and kept for history for a while, depending on the "Erase revisions for files unchanged in" setting in organization policies mentioned above. Now, when the "Rollback" function is initiated, for every single active file on a share, it will select the existing revision from history that is closest to the specified point in time, and will set this revision as active, pushing back the current one.

Use Case

This function is very specific, and the only viable use case for it is an encryptor ransomware or malware attack. Encryptor ransomware typically lurks for a while, silently encrypting the files and then asks the user to make a payment to get a decryption code, while malware can reside in a system for a while, infecting all the documents it can find with executable malware code. If local anti-virus software is not reliable or some new attack vector was used, this might go unnoticed for a while, and encrypted or infected revisions of files will be synced up to the cloud copy of the share.

In such a scenario, you would want to restore all files in the share at once to their previous states when these were not yet encrypted or infected. This is where this function comes to help; you just need to figure out when the infection or encryption has happened, and use "Rollback" to revert all the files to the point in time when it hasn't happened yet. When used outside of this specific case, this method is unwanted and dangerous. If not used properly for its intended use case, it will cause a lot of additional manual work to sort out.

Snapshot

This is your wayback machine. It creates a full clone of the given share, either in its current state or at a given time in the past. If some time is chosen, files that were active at that time but got deleted will be restored in the snapshot if these haven't been wiped out yet.

This function is very safe and absolutely non-destructive. It doesn't make any changes to the initial team share and does not modify it in any way; it always makes a full copy and then works only with the copy. When in doubt, use it first and see if that helps; you can always delete the unwanted copy if you haven't achieved the desired result.

It can be started by clicking on "Snapshot" button in the list of organization's team shares:

Which will then be followed by a snapshot parameters dialog:

Important things to understand and remember about this functionality:

• It is safe and non-destructive; it won't break anything and won't delete anything.
• It's really fast, especially in comparison to a wide range "Restore Deleted" done on a share with lots of deleted files.
• When used with the "Only include Data Up To The Following Point in Time" option, it's a very effective way to make a rolled-back copy of a share to a given point in time.
• Make sure you have enough space left in the quota to fit the full copy of a root. If needed, our Support team can quickly expand the quota for you.

How it works: the event processing for any given share is sequential - every event has its own unique ID, and these are chained in a strict ordered sequence. When this function is used without the "Only include Data Up To The Following Point in Time" option, it will simply do a 1:1 copy of the share in its current state. But when used with this option set, after making a 1:1 copy of the share, the system will find the very first event that happened just before the given time, and will truncate all the history of events for the cloned share beyond this point.

This means when "Only include Data Up To The Following Point in Time" is set, all the operations which were done beyond this point would be reversed - and added files will be removed, deletions, moves, and renames reversed, etc, and end result will be consistent for the given point in time. The whole operation is very fast, the longest part of it is when we're making a copy of all on-disk data for this cloned share, but this is also a pretty fast operation, as our storage can move big amounts of data around relatively quickly.

Use Cases

When the time is of the essence, especially in case of emergency, this is a preferred option. Main use-case for it is some drastic and massive deletion event: an angry employee deleting the whole share, or a user profile with synced shares being accidentally deleted. In such cases, the simple "Restore Deleted" process can take a long while to complete, while a snapshot of the share at the point in time just before the deletion can be created in under an hour, even for a very big share (typically taking just minutes to complete). The Clients can then be unsubscribed from the initial share and subscribed to the clone, reusing the existing on-disk folder of the initial share as a base folder for the snapshot, not downloading the whole share contents again from scratch. This will get the end users up and running again and give some time and breathing room to sort things out in the initial share if needed.

 SUPPORT | 720-204-4500 | 800-352-0248

• Contact Axcient Support at https://partner.axcient.com/login or call 800-352-0248
• Have you tried our Support chat for quick questions?
• Free certification courses are available in the Axcient x360Portal under Training 
• Subscribe to Axcient Status page for updates and scheduled maintenance