How to quickly restore large numbers of deleted Notes documents using scanEZ

A customer recently contacted us asking for help on an issue where one of her end-users deleted a large number of emails a few weeks earlier.

An admin’s first instinct here might be to restore the database from a backup of the appropriate date and have the end-user select and manually recover the emails that have been deleted.

Sadly, this wasn’t an option for our customer since a) the number of deleted docs was huge and b) the user couldn’t possibly identify them all. Furthermore, she had a number of valid reasons beyond the scope of this post that prevented her from being able to simply overwrite the production database with a restored backup (even if she added the missing documents that were created after the backup date).

What she really needed to do was to perform a merge to get the right collection of documents from a restored backup back to the production database.

Luckily for her this job is quite simple when you have scanEZ.

We’ll use this post to walk you through the steps we used to help her out. We thought that this example might be of interest to any beginner-to-intermediate scanEZ users out there as it makes use of a number of less-than-obvious features.

Before we get going, here are a couple of points to bear in mind:

1. When a document is deleted, a deletion stub is created (i.e. a note with a different Note Class but without the original document’s item contents).
2. The deletion stub maintains the original document’s UNID.

For this tip, we’ll need to take advantage of scanEZ’s ability to work with both documents and deletion stubs.

We’ll start by opening the production database where the emails were accidentally deleted in scanEZ.

From here we’ll launch scanEZ’s Deletion Stub Explorer tool (Fig. 1) in order to narrow down a selection of deletion stubs to a particular date and time (Fig. 2). We’ll use this to get a collection of deletion stubs from the date the accidental deletions took place.

The Deletion Stub Explorer grid (Fig. 3) lists all the information that’s still retrievable in deletion stubs. Here we’re able to examine properties like the UNID; NoteID; Deletion Times (both ‘officially’ and ‘in this file’); Sequence number; plus the remaining number of days before purging deletion stubs according to the database-level ‘Deletion Stub lifetime’ setting.

In this interface scanEZ won’t show the UNID column by default, we’ll need to right-click the grid and select this property from the ‘Grid Columns’ contextual menu (Fig. 4). We’ll also need to un-click all other properties to hide them, so that the only column displayed is the UNID.

Now that the grid is only showing UNIDs, we can simply select all 100 entries (Ctrl+A), then copy them to our clipboard (Ctrl+C).

With the list of UNIDs of the deletion stubs of the documents we would like to recover on the clipboard, we’ll begin the next stage by opening the restored version of this database in scanEZ.

Next we’ll use scanEZ’s ‘Search by UNID’ feature. Here we can paste the list of UNIDs and retrieve them all at once (Fig. 5).

After the ‘Search by UNID’ scan is complete, the retrieved documents will appear in a new MySelection virtual folder. From here we’ll tick the checkbox to select them all.

Next, we’ll right-click and choose Checkbox Selection>Copy to Another Database in the contextual menu. In the dialog that appears, we’ll choose to copy the documents to the production database (Figs. 6 and 7).

As the documents are being copied, scanEZ will automatically detect and overwrite the appropriate deletion stubs. This means the document will keep their Unique IDs.

Once the copying is complete, we can prove that everything worked as planned by simply searching for the same list of UNIDs in the production database: If we get a collection of newly restored documents—not the deletion stubs we started with—we know the process was successful.