Backups and recovery

It is a simple rule for surviving the loss of any one thing: keep three copies of your data, on two different types of storage, with one copy off-site. The original plus two backups, for example one on a local backup appliance and one in a separate cloud or at another location, means that a fire, a failed disk array or a stolen server does not take everything. Because ransomware attackers now look for backups and try to delete them, many guides extend the rule to 3-2-1-1-0: one copy that is offline or immutable, so that it cannot be changed or deleted even with administrator rights, and zero errors when the backups are verified and test-restored. For a small company, a practical version is a local backup for fast restores, an immutable cloud copy under separate credentials, and a regular, documented restore test.

An immutable backup is a copy that cannot be changed or deleted until a set retention period has passed, not even by an administrator account. It is usually achieved with write-once storage: object storage with a retention lock in compliance mode, a hardened backup repository that refuses deletion, or tape that is physically removed. The point is ransomware: attackers who gain admin rights routinely try to delete or encrypt backups before they encrypt production systems, so that the victim has no way back except paying. With an immutable copy, that step fails. Check three things when a vendor says immutable: whether the lock can be shortened or removed from the same console an attacker could reach, how long the retention lasts, and whether the storage provider's own support can override it. Immutability protects against deletion, not against backing up already-infected data, so keep several restore points.

It is a backup copy that has no permanent network connection to your systems, so an attacker inside the network cannot reach it. Classic examples are tapes or removable disks that are written, disconnected and stored elsewhere, and dedicated backup vaults that open a connection only during a short, controlled window. Some cloud services call an immutable, separately managed copy a logical air gap: it is not physically disconnected, but it is out of reach of your normal admin accounts. Offline copies are slower to restore and need discipline, because someone must actually rotate the media, check that the job ran and keep track of what is where. For most small companies the realistic target is one copy that is either physically offline or immutable under separate credentials, tested by restore at regular intervals. A copy that sits permanently on a share the whole network can reach is not offline, however it is labelled.

At least once a quarter for a sample of systems, after every significant change to the backup setup, and at least once a year as a full exercise of restoring a critical system from scratch. A backup that has never been restored is an assumption, not a backup: jobs that report success can still produce files that are incomplete, encrypted with a lost key or missing a database that was in use. A good test picks real systems, restores them to an isolated environment, checks that the application actually starts and the data is current, and records how long it took. That duration is your realistic recovery time, which is often much longer than expected. Write down what went wrong and fix it before the next test. Rotate which systems you test so that, over a year, every critical one has been restored at least once.

Very often, yes. Before they start encryption, attackers look for the backup server, the backup software console and any snapshots or shadow copies, then delete, encrypt or corrupt them so that the victim cannot recover without paying. MITRE ATT&CK lists this as Inhibit System Recovery (T1490), and the deletion of shadow copies appears in many CISA ransomware advisories. Backup administrator accounts and backup servers joined to the same domain as everything else are common weak points. Defences: keep at least one immutable or offline copy, run the backup system with separate credentials and multi-factor authentication, keep it out of the main domain where possible, and restrict which machines may connect to it. On the network side, connections to the backup server from machines that never normally talk to it are a warning sign. NetSenX's network map shows which hosts reach each server, and unusual internal connections are flagged as possible lateral movement.

Because ransomware encrypts every drive it can reach, and a mapped drive looks to it like any other folder. If a backup target is permanently mapped on a server or workstation, or reachable over a share with the same credentials, the ransomware on that machine will encrypt the backup files along with everything else, and the backups are gone at the moment you need them. The same applies to an external USB disk that stays plugged in, and to sync tools that mirror every change, including encryption, to the backup location. Better: let the backup software write to its target with its own service account that ordinary users and servers do not have, keep the target off the list of shares people browse, and add an immutable or offline copy. A quick check today: look at which machines have a drive letter or share pointing to the backup storage, and remove the ones that do not need it.

As few as possible: the backup server itself, the systems it backs up during their backup window, and the administrators' management workstation. Ordinary workstations have no reason to open file shares, remote desktop or management ports on the backup server. Write this down as a short rule set and enforce it with firewall rules or network segmentation, ideally putting the backup system in its own network segment. Then check that reality matches. Network flow data shows which hosts actually talk to the backup server, on which ports and when; in NetSenX the network map shows this on every plan, so a laptop in sales that starts connecting to the backup server stands out. Such a connection is not always an attack, but it always deserves an explanation, because reaching the backups is a typical step just before ransomware encryption.

Yes, in two different ways. The backup files themselves can be encrypted or deleted if the ransomware or the attacker can reach the backup storage, which is why immutable and offline copies matter. Less obviously, the backups can faithfully contain the attacker's presence: attackers are often inside a network for days or weeks before they encrypt, so recent backups may include their backdoors, scheduled tasks, new admin accounts or malicious files, ready to come back to life after a restore. That is why you keep several restore points over a longer period, restore into an isolated environment first, scan the restored systems, and check for accounts and remote-access tools that should not be there. Knowing when the intrusion actually began, from logs and network history, tells you which restore point is likely to be clean.

Do not start restoring until you know how the attackers got in and have closed that route, otherwise you restore into a network they still control. Then work in order: rebuild or verify a clean backup server and restore console first, with new credentials; change all administrator and service account passwords, including those used by the backup software; restore systems into an isolated network segment, not straight back onto production; choose a restore point from before the intrusion began, not just before the encryption; scan the restored systems and check for unexpected accounts, scheduled tasks and remote-access tools; and reconnect them step by step while watching their network behaviour. Keep the encrypted originals untouched until you are sure, both as evidence and in case a decryptor becomes available. With NetSenX in place, restored hosts that start regular outbound check-ins or unusual internal connections show up in the alerts.

Restore the foundations first, then what the business needs most, then the rest. A typical order: the network and security basics, such as firewall, switches, DNS, DHCP and the monitoring you will rely on; identity, meaning the domain controllers or cloud identity, rebuilt or verified clean, since every other system depends on it; the backup infrastructure itself; then the business-critical applications in the priority you decided in advance, for example order processing, production control or payroll; and finally ordinary file shares, workstations and less important services. Each step should include verification before the next begins. The order belongs in your recovery plan, agreed with management before any incident, together with the recovery time each system may take. Without that agreement, the first days after an attack turn into arguments about whose system matters most, while the clock is running.

They are the two numbers that turn a backup plan into a business decision. The recovery point objective (RPO) is how much data you can afford to lose, measured in time: with nightly backups your RPO is up to 24 hours, meaning a day's work could be gone. The recovery time objective (RTO) is how long a system may be down before the damage becomes unacceptable, measured from the incident until the system is running again. Set both per system with the people who own the business process, not only with IT: the accounting system might tolerate a two-day outage but no data loss, while a web shop might be the reverse. Then check whether your backups and restore tests actually achieve them. A restore that takes three days in a test cannot meet an RTO of four hours, however good the backup software is.

Not on its own. Sync tools are designed to keep every copy identical, so when files are deleted, overwritten or encrypted by ransomware on one device, the change is copied to the cloud and to every other device within a few minutes. Most services keep a version history and a recycle bin, and some offer to restore a whole library to an earlier point in time, which can save you after an incident. But that history has limited retention, it is controlled by the same account the attacker may have taken over, and nobody tests it like a backup. Treat sync as convenience and collaboration. For data that matters, add a real backup: a separate copy, under separate credentials, with retention you choose and restores you have tested. That applies equally to file servers that sync to the cloud.

Usually yes. SaaS providers work under a shared responsibility model: they keep the service available and protect it against their own hardware failures, but protecting your data against deletion, a malicious insider, a compromised account or a retention period that has run out is largely your job. Microsoft's own services agreement recommends that customers regularly back up their content. The built-in safety nets, such as deleted-item folders, recycle bins and version history, have limited retention and can be emptied by someone with the right access. A third-party backup of mailboxes, SharePoint and OneDrive, or the equivalent for Google Workspace, CRM and accounting systems, gives you an independent copy with retention you control. Check the restore process too: restoring one mailbox and restoring a whole tenant after an attack are very different jobs.

Yes. If the same domain administrator account that runs everything else can also delete backups, then an attacker who steals that one account controls both your systems and your way back. Give the backup system its own administrator accounts that are not members of the main domain or directory, protect them with multi-factor authentication, preferably phishing-resistant, and use them only from a dedicated management workstation. Service accounts that the backup software uses to read data from servers should have only the rights they need, and their passwords should be long, unique and stored safely. Where the backup product supports it, require a second person to approve deleting backups or shortening retention, often called four-eyes approval. Review who has backup admin rights at least twice a year and whenever someone leaves. These steps cost little and close one of the gaps ransomware attackers exploit most often.

Long enough to go back to a point before an intrusion began and to meet your legal and business needs, but no longer than necessary for personal data. Attackers often sit in a network for weeks before they act, and corrupted or deleted files are sometimes noticed only months later, so a few days of retention is rarely enough. A common pattern is daily backups kept for a few weeks, weekly ones for a few months and monthly or quarterly ones for a year or more, with at least the most recent part immutable. Legal retention rules, for example for accounting records, set minimums for some data, while the GDPR's storage limitation principle means personal data should not be kept forever just because it sits in a backup; document how deletion requests are handled for backup copies. Write the retention plan down and check that the backup system actually enforces it.

Yes, especially copies that leave your premises or sit with a cloud provider. A stolen backup tape, disk or cloud bucket is otherwise a complete copy of your company's data, and encryption turns it into useless bytes for the thief; under the GDPR, encryption is one of the security measures named in Article 32 and can affect whether a lost copy has to be reported to the people concerned. The hard part is the key. If the encryption key is stored only on the backup server and that server is destroyed or encrypted by ransomware, your backups are unreadable to you as well. Keep the key, or the recovery key, in a separate, documented place that does not depend on the systems being backed up, such as a password manager with offline access or a sealed copy in a safe, and include retrieving it in your restore tests. Encrypting backups protects confidentiality; it does not replace immutability.

Treat them as the most valuable systems you have, because after an attack they are. Put the backup system in its own network segment and allow only the connections it needs: backup traffic from the systems it protects and management access from a small number of admin workstations. Close remote desktop and file sharing on the backup server unless they are strictly required, and never use it for browsing or e-mail. Patch its operating system and backup software quickly; backup products themselves have had serious vulnerabilities exploited by ransomware actors. Use separate admin accounts with MFA, keep the server out of the main domain where you can, and keep at least one copy immutable or offline. Finally, watch it: new hosts connecting to it, connections at unusual times and large reads from the backup storage by machines other than the backup server are all signs worth investigating, and all of them are visible in network traffic.

A backup plan answers what is copied, how often, where it is stored and for how long. A disaster recovery plan answers how you get the business running again when something big breaks: who decides, which systems come back first, where they run if the original site or hardware is gone, how long each step may take, how staff and customers are informed, and how you know you are finished. Backups are one ingredient of recovery, not the whole recipe. Companies with excellent backups still lose weeks after a ransomware attack because nobody knew the restore order, the backup console needed a domain that no longer existed, or the only person who knew the passwords was on holiday. Write the recovery plan down, keep a copy outside your own systems, including on paper, and test it with a realistic exercise at least once a year, just as you test restores.

Back up the virtual machines with a tool that understands the hypervisor, so that you can restore a whole machine quickly, and also protect the hypervisor layer itself. Many current ransomware families include versions built to encrypt VMware ESXi hosts directly, which takes down every virtual machine on them at once. Practical points: keep the hypervisor management interfaces off the general network and reachable only from admin workstations; use separate, MFA-protected accounts for hypervisor and backup administration; disable services you do not need, such as SSH on hosts outside maintenance; patch hypervisors promptly; and make sure at least one backup copy sits outside the virtual environment it protects, immutable or offline. Hypervisor snapshots are useful for quick rollbacks but are not backups: they live on the same storage and disappear with it. Test restoring a full virtual machine to different hardware, because after an attack the original host may be unavailable.

It means restoring systems first into a separate, isolated environment, cut off from the production network and the internet, where they can be checked before they are trusted again. After a ransomware attack you rarely know at first whether the backups contain the attacker's tools or accounts, or whether the attacker still has access to the network. In a clean room, a small set of known-good infrastructure is built from scratch, often with fresh identity services; restored systems are scanned, their accounts and scheduled tasks reviewed and their behaviour observed, and only then are they moved into production. Larger companies prepare such an environment in advance, sometimes with a backup provider's help; smaller ones can plan for a spare server or a cloud account kept for this purpose. The point is not perfection but avoiding the most common recovery failure: restoring straight back into a compromised network and being encrypted a second time.

You cannot be certain, but you can reduce the risk considerably. Start with the timeline: from logs, endpoint data and network history, work out when the intrusion actually began, not when the encryption happened, and prefer a restore point from before that date for critical systems. Restore into an isolated environment and scan the result with up-to-date security tools, including the indicators of compromise from your investigation or from the relevant CISA advisory. Look for things that should not be there: new local or domain accounts, scheduled tasks, services and startup items, remote-access tools, and web shells on web servers. Compare the restored configuration against documentation or a known-good copy. Then watch the restored system's network behaviour before trusting it. NetSenX helps here: a restored host that begins regular outbound connections or scans other machines shows up in the alerts, while several quiet days are a useful, though not absolute, sign.

Almost nobody, and nobody alone. Deleting backups or shortening their retention is the action attackers most want to perform before encryption, so it should be harder than any normal admin task. Practical rules: only a small number of named backup administrators hold the right, using accounts separate from the main domain and protected by phishing-resistant MFA; deletion or retention changes need approval from a second person where the product supports it; immutable copies cannot be deleted by anyone until their lock expires; and every deletion is logged to a place the backup administrators cannot edit. Ordinary IT staff can run and monitor backups and restore files without being able to remove them. Review the list of people with these rights regularly and remove leavers immediately. If deletion is genuinely required, for example by a court order or a GDPR erasure request, document the decision and the approval.

No. NetSenX is a network detection and response service: it watches how devices on your network communicate and alerts you to signs of intrusion, such as beaconing, scanning, lateral movement and unusual outbound data volumes. It does not copy your files, databases, mailboxes or servers, and it cannot restore them after an incident. What NetSenX keeps is its own data about your network: the device inventory, connection metadata and alert history, with the retention set by your plan. That history is useful in a recovery, because it helps you work out when an intrusion began and which hosts were involved, and therefore which restore point is likely to be clean. For backups themselves you need a dedicated backup solution, ideally with an immutable or offline copy. NetSenX complements it by showing unusual access to the backup server and suspicious behaviour of restored systems.

Yes, and it is often forgotten. Network devices hold configuration that took years to build: firewall rules, VPN settings, VLANs, routing and access lists. If a firewall fails, is wiped by an attacker or has to be replaced after a compromise, rebuilding that configuration from memory takes days and usually introduces mistakes. Export the configuration automatically after every change and at least weekly, store the copies outside the devices themselves, ideally in version control so that you can see what changed and when, and keep at least one copy offline. Protect the exports, because they contain sensitive details and sometimes credentials or keys. A configuration history also has a security benefit: an unexpected new rule, account or port forward is a classic sign that someone has tampered with an edge device. Include restoring a device configuration in your recovery tests, ideally onto a spare unit.

Not by itself. A snapshot, on a storage system, a virtual machine or a file system, records the state of the data at a point in time, usually by keeping track of changed blocks rather than making a full copy. It is fast and very useful for rolling back a failed update or recovering a deleted file. But it normally lives on the same storage system as the original data, is managed from the same console with the same credentials, and disappears if that storage fails or an attacker deletes it, which ransomware operators routinely try to do. A snapshot becomes part of a real backup strategy when it is replicated to separate storage, protected against deletion, and tested by restore. Use snapshots for quick recovery from everyday mistakes, and keep independent, immutable or offline backups for the day the storage itself is the problem.