A restore test that starts by logging into the backup console with a domain account proves the backup works. It does not prove the organization can recover, because in a real incident the domain account, the console and the hypervisor that hosts it are all part of what went wrong. A cyber recovery drill inverts the assumption. Production is unavailable and untrusted, and the team has to reach the data anyway.
That inversion changes what is being tested. A routine restore exercises the software path. An adversarial drill exercises what that path quietly depends on, which is authentication, name resolution, a place to run, and the knowledge held by whoever is on shift. Those dependencies are invisible while production is healthy, since each one resolves automatically.
The scope here is deliberately separate from the ordinary restore program. How often to test, at what level, and what to measure are covered in the discussion of recovery testing cadence and measurement. What follows assumes that program already exists and asks a different question. When none of the usual starting points are available, where does the recovery begin.
Five assumptions define the exercise, and weakening any of them turns it back into a routine restore. Directory services are unavailable and untrusted, so no domain credential is used. DNS is unavailable, so nothing is reached by name unless the team brought the record with them.
The backup console is assumed compromised. Its configuration database, stored credentials and job history are treated as unreliable, so the drill does not begin by opening it. The hypervisor management layer is assumed compromised as well, so virtual machines holding backup infrastructure are neither available nor trusted.
Finally the administrator workstations are assumed compromised, including the password manager installed on them and any cached session tokens. This is the assumption teams resist most, and the one that exposes the real dependency, since almost every recovery plan silently starts with an administrator opening a saved credential on a familiar machine.
The drill cannot begin unless a small set of things lives where the compromised estate cannot reach. The first is credentials. A local administrative account on the storage system and on the backup software, held outside the production password manager, readable when every system is down. A sealed printed copy in two locations is unglamorous and works.
The second is reachability. The storage endpoint has to be contactable without production DNS, so the address is recorded in advance and the certificate chain needed to validate the connection is available offline. Teams often discover here that the endpoint certificate was issued by an internal authority whose revocation service is also down.
The third is the ability to read the data with a fresh installation. That means the installer and exact version of the backup software, a configuration backup and its password, and the encryption keys protecting the backup files. A console rebuilt without those can see the objects and decrypt none of them, which is why a recovery copy of the encryption keys is a prerequisite rather than a refinement.
The fourth is somewhere to run. A clean host built from known media, not joined to the domain, with enough capacity for the first few systems and a network path to the storage that does not depend on the production firewall management plane.
| Dependency | Where it normally lives | What the drill needs instead |
|---|---|---|
| Administrative login | Domain account, cached on a workstation | Local account, credential held offline in two places |
| Storage endpoint address | Internal DNS record | Recorded address and offline certificate chain |
| Backup configuration | The backup server database | Exported configuration and its password, stored separately |
| Backup file encryption | Console held keys | Key copy kept outside the backup system |
| Compute to restore onto | The production hypervisor cluster | An isolated host built from known media |
| Accurate time | Domain controller as time source | An independent source the clean host can reach |
Sequence matters more here than speed does. The first step is a trusted island, meaning the clean host, an address on it, a route to the storage endpoint and a correct clock. Nothing further works reliably if the clock is wrong, since TLS validation and token lifetimes both fail in confusing ways.
The second step is proving read access to the backup data with the offline credential, before any recovery software is involved. Listing buckets and objects with an ordinary S3 client shows whether the data is reachable and the retention dates intact, separating a storage problem from a backup software problem while there is time to react to either.
The third step is standing up backup software that can read the repository, then selecting a restore point. Both carry risk. A fresh installation has to import or rescan the repository rather than trust configuration from a compromised server, and the selection is a judgment about when the intrusion began, the work described in choosing a clean recovery point.
Only then does the identity layer come back, and this is the most delicate part of the sequence. A directory restore brings back whatever persistence the attacker established inside it, so the drill treats that restore as a candidate to examine rather than a step to complete. Everything that authenticates against the directory waits behind it, which is why the count of systems that need it is worth knowing before the drill.
The most common stopping point is authentication. The team reaches the storage or the backup software with no credential that works without the domain, so the drill ends within the first hour. That outcome is still useful, since the finding is specific and fixable, but it is not a completed exercise.
The second is licensing and activation. Backup software and some operating systems expect to contact a license service, and an isolated recovery environment has no path to one. Whether that failure blocks restores or degrades quietly is worth knowing before an incident rather than under pressure.
The third is capacity. Restoring a meaningful subset requires somewhere to put it, and teams that have not reserved it end up narrating the remaining steps instead of performing them. Naming the point where the drill turned into discussion, and what was assumed beyond it, keeps the record honest.
ARTESCA is object storage software used as a backup target, with immutable backup storage through S3 Object Lock and an S3 compatible API. In a drill of this shape that API is what makes the second step possible, since a generic S3 client on a clean host can authenticate with a local access key, list objects and confirm retention state with no backup console involved.
Because ARTESCA is deployed on infrastructure the customer runs, its network placement, administrative accounts and key management are the customer's decisions. That matters here, since whether the storage stays reachable while the production domain is down depends on choices made at deployment rather than on the product.
The same locality applies to identity. A storage system whose administrators authenticate locally stays usable during a directory outage, which is a practical argument for keeping backup infrastructure off the domain rather than an abstract one.
The artifacts the drill depends on decay faster than the plan does. Keep one recovery record listing the storage endpoint address, the bucket names, the local account names, the backup software version and patch level, the configuration backup location and the key custody arrangement. Short enough to print, specific enough to act on without interpretation.
Refresh it on events rather than dates, since events are what invalidate it. A storage upgrade, a backup software upgrade, a certificate renewal, an address change, a staff change affecting credential custody. Any of those makes part of the record wrong, and a record wrong in one field is usually trusted in all of them.
Record what stopped the last drill, and what was assumed past that point, in one paragraph beside the recovery record. That paragraph is the agenda for the next attempt, and reading it first is the cheapest way to make the second drill reach further than the first.