OneDrive: Delete and Restore

In my OneDrive workshops, which I hold for midsize and enterprise companies, the topic of deleting and restoring always leads to discussions. Deleting is so easy, but when it comes to restoring, administrators sometimes get confused. The truth is, once you understand how OneDrive’s file versioning works, restoring is straightforward, if a bit clunky.

The Scenario

We have two users in the company (Hans and Julian) who are working on a new concept with several Office documents. The content is still being formed, so Hans has created a folder in his OneDrive for Business that contains the documents. He shares the folder with Julian, so Julian can also synchronize this folder with the content on his device. This saves the annoyance of having to search through the shared documents.

Even if only one file is to be synchronized with the recipient, this file must be saved in a folder, which must then be shared with the recipient. This also works with multiple recipients. Otherwise, the file can only be edited in the browser.

We can note several things in Figure 2, above. The name at the top of the folder is who shared the file (position 1). Classic Sync works (position 2), but Julian will use Add shortcut to My files (position 3). 

Now, as shown in figure 3, when Julian clicks on My files (position 1), there is a shortcut to the shared folder (position 2).

Note: Why use a shortcut? You can read an article about it here.

The scenario now allows both users to work on the documents, not only individually, but also together. In this case, the elements of a document must be locked by the system during editing. In the first days of the implementation of collaborative working, the locks of Office elements were still a bit more generous (in Word a paragraph, in PowerPoint a slide), but this has now changed: Word a word, Excel a cell, PowerPoint an object) and thus is no longer noticeable to users. Whoever clicks first in a cell in Excel locks this cell for the other user(s). You can see where others are working by their different-colored cursors.

While they are collaboratively working, the document is simultaneously stored on Hans' and Julian's devices and in the cloud, i.e., in Hans' OneDrive for Business. All changes are permanently synchronized and thus the different versions are also generated in the cloud. Neither user needs to save the document manually (CTRL + S); this happens automatically. Working together is also possible in the Office browser apps.

Deleting a Shared File

Let's return to our scenario. Hans has shared the folder in OneDrive for Business, Julian has synchronized the folder, and both are working on the documents contained in it. Both are using the desktop versions of Word. And then it happens. Julian accidentally deletes a document. And now comes the question: How can Julian recover the document?

Let's first look at what happens when the document is deleted by Julian:

• First, the document is moved to the local Windows Recycle Bin on Julian’s device.
• The deletion process is then reported to the cloud.
• Finally, the deletion process reaches Hans’ computer, and then moved on Hans’ device to the Windows Recycle Bin.

When Julian accidentally deletes the document, he receives a warning that he should not ignore it.

Until a few months ago, this warning did not pop up. Now that it does, it is still not very helpful. Clicking on Learn more explains some things, but the essentials are not explained. The most important part of this warning is: These files can be restored from the owner’s recycle bin (without loss of metadata like versioning, and only if you use the Recycle Bin of the web version of OneDrive for Business).

We saw that Julian could go to his local Windows Recycle Bin, identify the document, and click Restore. Doing so used to result in a prompt to rename the document. Why was that? The answer has to do with versioning.

On local devices we always see only the newest version. The same is true for synchronized files. On SharePoint, the versioning function provides for the automatic creation of versioning. In the file itself, changes are logged and recorded. But since the versioning is not included in the file itself, only the newest version is synchronized to the local devices.

As with local devices, the display of an office file in the browser is always the newest version. Unlike the local devices, one can view the different versions, compare, download, and also restore an older version. And if the SharePoint administration has not restricted the versioning, users have no limit on the number of versions they can see or restore. The whole thing is called Shredded Storage, and of course it also uses cloud drive space. However, it doesn’t do so as much as one might think, as the file is not completely re-stored with every version; only the changes are. And anyway, the user does not notice any of this; they only see that they can choose different versions of the document.

Managing Storage Space and Versioning

It is possible as an administrator to switch off versioning completely, but I do not recommend this. If you have concerns about storage consumption on SharePoint, then you should limit versioning to a certain number. When the limit is reached, the oldest version is removed and is therefore no longer available for recovery, and a new version is added.

This also exposes the limitations of conventional data backup. Many third-party providers only back up the file and not the metadata, which contains the versions. In case of a possible restore from this backup, only the last state is available. In the past, during a local restore, Windows recognized this had happened and asked me to rename the file. Unfortunately, it didn’t mention why it wanted me to do that.

If the deleted file had the status Cloud Only on the device before deletion, it will not be moved to the local trash, because only basic data like file name and extension, creation date, change date, attributes and image were anchored to the local NTFS (New technology file system). So if the file content is not available locally, the file would have had to be automatically downloaded first, which makes no sense when it is only going to be deleted.

At the same time as the delete command is sent on the local computer, it is also sent to the cloud. There, the delete command is also sent to other devices of the persons involved. Then the file is moved with all possible metadata (versioning) to the server-based recycle bin and is kept there for 93 days.

Extending the Recycle Bin Time

Keeping a file in the recycle bin longer than the default 93 days can only be done with a solution from MVP Haniel Croitoru, which was described in this TekkiGurus article. I spoke with Haniel at the Microsoft MVP Summit in Redmond, and he confirmed that the move to another SharePoint document library described in his article scales even with many deletions, but currently does not take version history into account. In addition, this Power Automate solution would have to be adapted to the Site Collection of OneDrive for Business. However, keep in mind that in our scenario, Hans has shared the folder from his OneDrive for Business, which is another SharePoint Site collection.

The delete command will reach Hans’ computer, either immediately if it is currently on, or whenever it is next started up.

And the procedure is the same as for Julian's computer. Everything written in the paragraphs above about deleting on the originating computer also applies to this user.

Restoring a Shared File

User Julian immediately notices that the file was deleted. If he doesn't want to give up the history of the file, he doesn't have many options:

• Local Restore.
  Does not contain version history information.

• Access to the server-based recycle bin.
  Unfortunately, this does not work either, because Julian does not have the rights for this. The file is stored in Hans’ server-based recycle bin in OneDrive for Business. He is the administrator there.
• Communication with the owner.

The third and last possibility is for Julian to communicate with Hans, who would restore the file. And because of the missing history, Hans must restore the file in the browser, as shown in Figure 9, below: 

• Switch to OneDrive in Bowser. 
  Switch to the server based recycle bin (position 1).
• Identify the deleted file.
  Select the file and click on Restore (position 2).

The file is restored with all the metadata and versions in the same place and then synchronized to Hans and Julian’s computers.

Summary

Restoring in OneDrive for Business is not easy. Mishaps happen. Microsoft hints at the difficulties with a popup message but doesn't fully explain them. The above scenario describes an everyday procedure with two users, but it can be extended to include additional users at will.

Change Manager and User Adoption Manager point out that such files do not belong in OneDrive for Business. I disagree, because you don't have to create a document library in SharePoint to build them up. On the one hand, this is easier in OneDrive for Business, because a user is the administrator, but on the other hand, the user can decide this himself, immediately, so he does not have to wait for the SharePoint administrator. This is also one of the reasons why every user gets his own SharePoint site collection with OneDrive for Business. And this can range from 1 TB to 25 TB, depending on the license plan, without reducing the organization's storage quota.

The important thing for all users to understand is: Who owns the file? Version history is not important for some, but for others it is. The old version of OneDrive required renaming the file; with the new one there are no more hints, except the warning, which I have already described above.

I hope you find this useful!