TECHNET
TECHNET / Insights / Backup

Why your backup server should refuse to delete

Append-only, encrypted, off-site: the design that keeps history safe even if an attacker gets in.

By TECHNET Engineering · 1 Oct 2026 · Backup

Most backup failures are not disk failures — they are access failures. An attacker (or a mistaken script) gets the credentials a server uses to back itself up, and uses them to delete the backups too.

The fix: a server that can only add

In an append-only repository, a client may upload new data but cannot delete or rewrite old data. Retention (pruning old copies) is done by the backup server itself, on a schedule, using credentials the clients never hold.

Three habits that matter

  • One login per system. A compromised web server should not be able to read, let alone touch, your mail backups.
  • Encrypt at the source. The backup store only ever sees ciphertext. Keep the repository passphrase in your password vault — without it the backup is unreadable.
  • Watch for silence. A backup that stopped last week looks identical to one that is fine. Alert when any repository has not been refreshed in 36 hours.

Test the restore

A backup you have never restored is a hope, not a plan. Schedule a restore drill onto a fresh machine and time it.

Want this for your business? Talk to us — or see the services behind this article.

← Back to Insights