After a ransomware event, the first screen most teams open is the backup console. It lists jobs, restore points, last successful runs and repository contents, and it does so in a familiar layout that invites belief. The console runs on a domain-joined Windows server that held credentials to the hypervisor, the directory and the storage. If that server was touched, the screen is reporting on an incident it was part of.
This is not a reason to ignore the console. It is the fastest route to an inventory of what should exist, and its records are usually accurate. It is a reason to know which of its statements are independently verifiable and which are assertions made by a host the attacker may have held for weeks.
The distinction is practical. Recovery decisions get made in the first hours, often from a single view, and the cost of trusting the wrong line is a restore that reintroduces the intrusion.
A backup server is unusual in an estate because it needs broad, standing access by design. It authenticates to the virtualization platform to snapshot machines, to file servers and databases to run agents, to the storage platform to write data, and often to the directory itself. Little else in a mid-market environment holds that combination in one place.
It is also discoverable. The product name appears in service names, scheduled tasks, firewall rules and software inventories, and the server is usually joined to the same domain as everything else so jobs can authenticate without manual credential handling. An intruder mapping an environment finds it quickly, and it is worth more than any file server.
What follows from that is uncomfortable but simple. In an incident where the domain was compromised, the backup server should be treated as compromised until evidence says otherwise, and evidence has to come from somewhere other than the backup server. Which components survive that assumption is the subject of what survives a compromised backup server.
Almost everything the console displays is read from its own database. Job history, success and failure states, restore point chains, retention labels and repository capacity are values the backup server computed, stored and is now reading back, not live queries against the storage.
That matters because those values can be wrong for ordinary reasons as well as malicious ones. A job can report success after writing to a target that was later emptied. Capacity figures can be hours old. Retention labels in the catalog describe what the software intended, which is not always what the storage recorded.
A few views are different. Anything the console fetches live from the storage endpoint reflects the storage platform's answer rather than the local database. Knowing which views those are in the product in use is worth ten minutes with the documentation before an incident rather than during one.
| What the console states | Where the statement comes from | How to corroborate it |
|---|---|---|
| Last night's job succeeded | Job history in the backup server database | Object creation timestamps and sizes in the bucket for that job |
| This restore point is immutable until a date | A retention label the backup server wrote | The retain-until value the storage API returns for the object version |
| Repository used capacity | Values computed and cached by the backup server | Bucket usage reported by the storage platform itself |
| No backups were deleted | Absence of entries in the server's own log | Storage-side access logs and version listings, held separately |
| The backup passed its health check | A check run by the same software that wrote the data | An actual restore into an isolated network |
Object storage keeps its own record, and that record is reachable without the backup application. A listing of object versions in the bucket gives creation timestamps, sizes and version identifiers. A head request on a version returns its retain-until date and lock mode as the storage platform holds them, not as the catalog describes them. Access logs, where they are enabled and shipped elsewhere, show which identity issued which call and when.
Those facts answer more than they appear to. Steady nightly object creation that stops abruptly narrows the window in which something changed. A burst of writes outside the usual schedule is worth explaining. Delete calls refused because of retention are a direct signal that something with valid credentials tried to remove protected data.
The value of all this depends on one condition, which is that the storage platform does not authenticate against the same directory as the backup server and is not administered from the same workstations. Where the storage side shares an identity plane with production, its records inherit the same doubt. That separation is the argument made in keeping backup infrastructure off the domain.
The strongest available check is a restore performed into an isolated environment, with no route back to production and no domain membership. It confirms that the objects are readable, that the chain is complete, that the encryption keys work, and that the restored workload boots. Nothing derived from the backup server's database can substitute for that result.
The restore has to be examined rather than just declared successful. A machine that boots is not automatically clean. The useful questions are whether scheduled tasks and services match a known baseline, whether the accounts present are the accounts expected, and whether the file system shows encryption activity before the restore point. Picking the candidate to test is covered in choosing a clean recovery point.
Where possible, run the restore from a backup server installation that is not the original one. A fresh installation with an import from the bucket removes the catalog from the trust chain entirely, and it also measures how long that import takes, which is a number worth having in advance.
ARTESCA is object storage software used as a backup target, deployed on infrastructure the customer runs. It presents an S3-compatible API and supports S3 Object Lock, so retention on an object version is held and enforced by the storage layer rather than by the application that requested it. A query against the API returns what the storage platform holds, whatever the catalog says.
Because the deployment is on customer infrastructure, its identity boundaries are a customer decision. Administrative access can be kept out of the production directory, and the credentials the backup software uses can be distinct from an administrator's. Whether that separation exists determines how much independent evidence is available after an incident.
Capacity ranges from roughly 50 TB to 8.5 PB, and the platform is designed as a target for Veeam and other backup software. Its records are generated by a different system than the one under suspicion, which is the point.
Write down, in advance, how to list the contents of the backup bucket without the backup application. That means an S3 client on a machine that is not the backup server, read-only credentials stored somewhere other than the console, and a short procedure for listing versions and reading retain-until dates. Ten lines, tested twice a year.
Ship storage access logs off the storage platform to a destination the backup server cannot write to. The value of an access log during an incident depends on confidence that nobody edited it, and that confidence comes from where it is kept.
Finally, build the independent restore into the testing routine instead of leaving it for the incident. One restore per quarter from a fresh installation, into an isolated network, with the boot result and elapsed time recorded, establishes a procedure and a baseline. A full drill that assumes production is unavailable is a larger exercise, described in running a cyber recovery drill with production down, but the quarterly version is small enough to actually happen.