Why Backups Should Be Stored in Another Location: Same-Server Risks Explained

Last reviewed: 17 August 2026. A backup is useful only if it survives the incident that makes the production system unavailable. That is why copying data to another folder, another disk, or even another virtual volume on the same server is not enough for a serious recovery plan. The copy may protect against a deleted file, but it can still disappear with the same hardware failure, ransomware event, account compromise, storage corruption or data-centre incident.

Practical rule: production data and recovery data should not share every failure domain. Keep at least one recoverable copy on infrastructure that is operationally independent of the production server, and test that copy before you need it.

Advika's current public guidance already places responsibility on customers to maintain independent backups and not rely on the provider as the sole backup location. The exact scope of any separately purchased managed-backup service should always be confirmed in the quotation or service agreement. This article explains the infrastructure reason behind that policy and how to design a safer second or third location.

Why a backup on the same server can fail with the original

The easiest backup to create is often a local copy: a database dump in another directory, a control-panel backup stored under the same account, or a snapshot written to storage attached to the same host. These copies can be convenient for quick rollback, but they are not independent recovery copies when they share the same failure path as production.

Consider what can happen when the backup remains on the same server:

• Disk or storage failure: if the underlying storage device, RAID set, controller or filesystem fails, both production data and the local copy may be affected.
• Ransomware or destructive malware: malware running with sufficient access can encrypt or delete both the active data and any writable backup mounted beside it.
• Administrative error: an incorrect cleanup command, filesystem resize, reinstallation or control-panel action can damage every copy reachable from the same administrative context.
• Credential compromise: if an attacker obtains root, administrator or panel access, a backup stored under the same credentials may be just as exposed as the live workload.
• Host or facility outage: a backup that depends on the same physical host, power path or local facility does not help when that whole failure domain is unavailable.

NIST's ransomware recovery guidance explicitly recommends carefully planned and tested backup and restoration strategies, and says backups should be isolated so ransomware cannot readily spread to them. The important word is isolated. A backup is not made resilient merely by giving it a different filename.

Same-server, same-site and off-site backups solve different problems

Backup design becomes clearer when every copy is mapped to the failure it is expected to survive. A fast local snapshot and a remote recovery copy can both be valuable, but they have different jobs.

This is why “we take daily backups” is an incomplete statement. A buyer should ask where those backups are stored, who can delete them, how long they are retained, and how restoration is tested.

What a genuinely independent third location changes

A third location is valuable when it breaks dependencies that the first two copies still share. For example, production may run on a VPS and a second copy may sit on backup storage in the same facility. A third copy in another location can provide a recovery path if the facility, network access, administrative account or local storage platform suffers a wider incident.

Geographic separation is only one dimension. Administrative separation matters too. If the same password, same root account and same always-mounted write access can delete every copy, geographical distance alone does not provide strong protection. Good separation can include:

• different credentials or a dedicated backup service account;
• restricted write and deletion permissions;
• retention or immutability controls where available;
• a separate storage system or provider account;
• an off-site region or facility appropriate to the business's recovery objective;
• monitoring that alerts when scheduled backups fail or stop changing;
• documented restore credentials and recovery steps stored securely.

NIST also recommends protected off-site backups in its recovery guidance for cyber incidents. The operational objective is not simply distance; it is to prevent one incident from consuming every usable recovery copy.

Backups are not complete until restores are tested

A backup job reporting “success” proves that a process ran. It does not prove that the resulting data is complete, consistent or restorable. Database backups may be corrupt, application files may be captured without required configuration, encryption keys may be missing, or an archive may exist while the team no longer knows how to rebuild the service around it.

The 2026 NIST SP 1339 OT Backup Quick Start Guide states that effective backup management includes regular creation, testing and review during recovery exercises. Although that publication focuses on operational technology, the recovery principle applies cleanly to hosted infrastructure: an organisation should prove that its backup can recreate the service it is meant to protect.

A practical restore test should answer:

1. Can the backup be located without relying on the failed production server?
2. Can authorised staff access it with documented credentials?
3. Can data be restored into a clean environment?
4. Does the restored application start and pass basic integrity checks?
5. Are databases, uploads, configuration, certificates and secrets all present?
6. How long does the restore actually take?
7. How much data is lost between the last usable backup and the incident?

The last two questions connect backup design to recovery objectives. A business that can tolerate one day of lost changes has a different schedule from a transaction system that needs much shorter recovery points. Backup frequency, retention and replication should be chosen from the workload's recovery requirements, not copied from a generic hosting checklist.

How to design a safer backup layout for a VPS or dedicated server

Start by classifying the data. Operating-system packages can often be rebuilt. Customer uploads, databases, application secrets, configuration, mailboxes and business records may be much harder to recreate. Back up what is irreplaceable first, then include enough system state to make restoration predictable.

For a typical hosted workload, a practical layout can look like this:

1. Production: the live VPS, cloud instance or dedicated server.
2. Local recovery layer: short-retention snapshots or backup storage used for fast restoration from routine errors.
3. Independent recovery layer: a separate location, account or storage system with longer retention and limited deletion rights.
4. Recovery testing: scheduled test restores into a clean environment, with results recorded.

If the workload is especially important, add versioned or immutable retention so a compromised administrator cannot simply erase the clean history. The precise technology can vary; the design requirement is that the recovery path remains available when production is not.

Questions to ask a hosting or backup provider

Do not accept “backup included” as the final specification. Ask for the operational details in writing:

• Is the backup stored on the same physical server, the same storage array, the same facility, or a different location?
• Is it a snapshot, a file-level backup, an application-aware backup or a full-image backup?
• What is the backup frequency and retention period?
• Can the customer download or export an independent copy?
• Who can delete backups, and are deletion controls or immutability available?
• Are backups encrypted in transit and at rest?
• How is a restore requested, and what restoration time should be planned for?
• Are restore tests included, customer-triggered or entirely the customer's responsibility?
• What happens to backups when the service is cancelled or suspended?

Advika's infrastructure portfolio includes different cloud and dedicated operating models, so the backup design should be confirmed for the specific service rather than inferred from a general product category.

Common backup mistakes to avoid

• Calling RAID a backup: disk redundancy can help service continuity after a drive failure, but it does not preserve an independent historical copy after deletion, compromise or corruption.
• Keeping every copy online and writable: this increases the chance that one compromised account can destroy the recovery set.
• Backing up data but not dependencies: a database without its application configuration, keys or uploaded files may not produce a usable service.
• Never testing restores: untested backups can create false confidence.
• Using only one retention point: corruption or compromise may remain unnoticed until the newest backup contains the same problem.
• Assuming the hosting provider owns the whole recovery process: responsibility depends on the purchased service and contract.

Frequently asked questions

Is a backup on another disk in the same server enough?

It is better than having no copy, and it may help with some disk-level failures, but it still shares the server, administrative and often facility failure domains. Keep an independent recovery copy elsewhere for important data.

Why is a third backup location useful?

A third location can protect against incidents that affect both production and the first backup layer, such as a site outage, widespread credential compromise or destructive attack. The third copy should also be administratively separated where practical.

Should backups always be in another city?

Not necessarily. The correct separation depends on the risks and recovery objectives. Geographic separation is useful for site-level incidents, while credential, account and storage separation protect against different failure modes.

How often should a restore test be performed?

There is no universal interval. Test often enough to prove that the process still works after application, database, infrastructure or staff changes. Critical workloads usually justify more frequent exercises than static or easily rebuilt systems.

Does a snapshot count as a backup?

A snapshot can be part of a backup strategy, but a snapshot tied to the same platform is not automatically an independent backup. Verify its storage location, retention, deletion controls and whether it can be exported or restored when the original service is unavailable.

Bottom line

The main disadvantage of taking backups only on the same server is common-mode failure: the incident that damages production can damage the backup at the same time. A separate storage layer reduces some risk; an independent off-site or third location reduces more. The strongest design combines separation with restricted access, sensible retention and tested restoration.

For Advika customers, treat provider-side backup features as one layer, not the only copy. Confirm the exact backup scope in writing, maintain an independent recovery copy, and test the complete restoration process before a real incident forces you to learn it under pressure.