News
eDiscovery from your backups: finding the data when legal, HR or a regulator asks
When legal, HR or a regulator asks for “everything about X”, the data is often already gone from the live tenant, but it is still in your backup. Here is what eDiscovery asks of IT and MSPs, and how the new eDiscovery action in the Duplicati Console finds the matching Microsoft 365 or Google Workspace content and hands it to the right person.
The email usually arrives on a Thursday afternoon. Legal needs every message a former sales manager exchanged with one customer over the last eighteen months. HR needs the files a departing employee touched before they resigned. A customer has filed a data subject access request and the clock is running.
None of these are restore requests. Nobody wants the data put back. They want it found, collected and handed to a specific person, without the rest of the mailbox coming along for the ride.
That job has a name, eDiscovery, and for most small and mid-sized organizations it lands on IT or on their MSP. This article covers what the job involves, why your backup is often the best place to do it, and how the new eDiscovery action in the Duplicati Console handles it for Microsoft 365 and Google Workspace backups.
What eDiscovery actually asks of IT
eDiscovery is the process of locating electronically stored information and producing it for a legal, regulatory or internal matter. The term comes from litigation, but the same four steps apply to an HR investigation, an audit or a privacy request.
Identify where the relevant data lives: which mailboxes, drives, sites and chats, and for which period.
Preserve it, so nothing relevant is changed or deleted while the matter is open.
Collect the items that match, and only those.
Hand over the collection to the person who will review it, in a way that shows where it came from.
Lawyers and HR decide what is relevant. IT's part is to make these steps fast, complete and defensible. The hard cases are almost never about searching a healthy mailbox. They are about data that is no longer where it used to be.
Why the live tenant is not enough
Microsoft 365 and Google Workspace both ship discovery tools, and for data that still exists in the tenant they work well. The gaps appear in three places.
The data has already left. A request rarely concerns last week. It concerns a project from last year, an employee who left in the spring, or a folder someone cleaned up. Recycle bins and deleted-user grace periods are measured in days or weeks, and a native search can only find what the platform still holds. A hold only protects data from the moment it is placed.
The tool is not in your plan. The fuller discovery features in both platforms sit in the higher licence tiers. Many small organizations, and many MSP clients, run on plans that include little or none of it. Finding that out on the day the request arrives is a bad time to start a licence upgrade.
The question is about the past, not the present. "What was in this mailbox on 3 March?" is a different question from "what is in it now?" A live tenant shows the current state. A backup holds a series of versions, so you can search the data as it was at a given point in time, including items that were later edited or removed.
A backup that runs daily and keeps its versions is, in effect, an independent record of the tenant. It was built for recovery, but it answers discovery questions for the same reason: it kept a copy that nobody in the tenant could quietly change.
How eDiscovery works in the Duplicati Console
eDiscovery is an action on every managed Microsoft 365 and Google Workspace backup in the Duplicati Console. It searches the backup for content and shares the matching files with a recipient you choose.
You find it on the Managed backups tab under Machines, in the actions menu next to Restore. The two actions are close relatives, and the difference is the point:
Restore | eDiscovery | |
|---|---|---|
Starting point | You know which user, folder or item you want | You know what you are looking for, not where it is |
How you select | Browse the tree, or search by name | Search the backup for content |
Where the result goes | Back into a tenant, or to a download | To a named recipient, as a shared set of matching files |
Needs write access to the tenant | Yes, when restoring into a tenant | No |
Three properties of managed backups make this practical:
Nothing to install. The search runs on a Duplicati-hosted runner that starts on demand and shuts down when the work is done, the same way backups and restores run.
The tenant is not touched. The search reads the backup, not the live mailbox. Users are not notified, nothing is restored into production, and the backup application can stay read-only.
Reviewers stay out of the Console. The person who runs the search and the person who receives the result are different people. Counsel or HR receive the matching files without an account that can see the rest of the backup.
The step-by-step guide, with the search options and how the recipient gets access, is in the eDiscovery documentation.
Four requests it is built for
The request | What makes it hard in the live tenant | What the backup adds |
|---|---|---|
Litigation or regulator request. "Everything about contract X between these dates." | Some custodians have left, and their accounts are gone | Mailboxes and files of departed users are still in the backup versions |
HR investigation. "What did this person send and store before they resigned?" | The person may have deleted things, and must not be alerted | A search of the backup is invisible to the user and unaffected by their clean-up |
Data subject access request. "Give me the data you hold about me." | The data is spread over many mailboxes and drives, and the deadline is fixed | One content search across the backed-up tenant, with the result shared to the privacy lead |
Departed employee. "The client says they sent the signed version to Maria in 2025." | The licence was removed months ago | The item is found and shared without restoring a whole mailbox into a live account |
For MSPs, each row is also a billable service. Clients rarely plan for discovery, but they remember who solved it in an afternoon.
Use it carefully: what to decide before the first request
Searching every mailbox in an organization is a powerful capability, and it deserves the same care as the data it touches. Four things are worth settling in advance.
Who may ask, and who may run it. A search should start from a documented request by legal, HR or the privacy lead, not from curiosity. Keep the number of people who can run one small. For an MSP, agree with each client who is allowed to request a search on their behalf.
Keep the scope narrow. Search for the matter at hand: specific people, dates and terms. A narrow search is faster to review and easier to justify under data-minimization rules.
Retention sets the horizon. eDiscovery can only find what the backup still holds. If your retention keeps 90 days of versions, a question about last year has no answer. Match your retention schedule to the periods your sector expects you to answer for.
Do not archive a backup that is part of an open matter. An archived managed backup keeps its data, but Restore and eDiscovery are no longer available for it from the Console.
It also helps to be clear about what the feature is not. It is a way to find and hand over data, not a review platform with tagging and redaction, and not a substitute for legal advice on what must be preserved or produced. For organizations with confidential processing enabled, managed backups, and with them eDiscovery, are not available.
Getting started
If you already run a managed Microsoft 365 or Google Workspace backup in the Duplicati Console, eDiscovery is in the actions menu today. Open the Managed backups tab, pick the backup and choose eDiscovery.
If you do not have a managed backup yet, the order matters: discovery can only reach back as far as your first backup. Setting one up takes a tenant app registration and a short wizard, and the console then runs the backup on a schedule with no machine to maintain.
The request will come on a Thursday afternoon. The backup that answers it has to have been running since long before.



