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.

Part 1: Finding missing document unique IDs.

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.

Fig.1 – Launching the Deletion Stub Explorer tool

Fig.2 – Narrowing down a selection of deletion stubs to a particular date and time

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.

Fig. 3 – Deletion Stub Explorer with a narrowed display based on the date parameters that we entered

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.

Fig. 4 – Selecting to display only the UNID column

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).

Part 2: Finding and recovering missing documents.

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).

Fig. 5 – Entering a list of UNIDs in scanEZ’s ‘Search by UNID’ dialog

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).

Fig. 6 – Using the Checkbox Selection menu to copy the documents from the MySelection folder to the production database

Fig. 7 – Selecting the destination database for the copied documents

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.

Fig.8 – Confirmation that the documents were copied

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.

Keep me posted on more like this!

We’ll keep you up to date on new technical articles, tips and tricks, and upcoming events.

We don’t spam, and you can unsubscribe at any time.

Share This