Skip to content

InterServer's "nightly" backup was 14 days old, my manual one saved me

Reviews by frankfurt_ops 3 replies 199 views
#1

MySQL Database Corruption and Backup Failure at InterServer

Please to share my Experience from last Week with the Community.

  • The Incident: on 2025-10-02 at 03:17 UTC the MariaDB Instance on InterServer shared Node omega-44 failed with InnoDB Page Corruption Errors.
  • The Recovery Attempt: InterServer Support restored from their "nightly" Backup. Timestamp of that Backup: 2025-09-18. Gap of fourteen Days.
  • The Discovery: my own manual Backup from 2025-10-01 at 22:00 UTC was newer. I had used mysqldump with --single-transaction.
  • The Result: Data Loss limited to five Hours instead of fourteen Days.

Lesson: Trust no automated Backup Schedule without Verification.

Please to verify your Backups regularly.

Regards,
Dieter Müller
2025-10-09 08:42 CET

#2
Route to InterServer backup server:
  1  192.168.1.1    0.5ms
  2  10.32.0.1      1.2ms
  3  interserver.net  89.3ms  <-- route via Secaucus adds 67ms vs direct
  4  * * *
  5  storage-node-07  timeout

Route via Secaucus adds 67ms and apparently packet loss at hop 5

Not surprised their "nightly" fails silently

1ms or I don't want it
#3

This is why we make test restore every month my friend!!! I learn this the hard way with CloudCone in 2023 their backup was from 22 days before hahaha I lost everything but static files now I have 3-2-1 rule and also borgbase extra copy is very good — I use https://www.borgbackup.org for that now

InterServer should pay you for finding this bug lah

ping so high I wave back
#4

Hey folks

Friendly reminder that naming specific support agents or posting internal ticket numbers falls under our no-doxxing rule — not happening here yet, just heading it off

This thread is a great example of why we have the backup verification wiki page

Carry on

~be kind or be gone~

Post a reply

You need an account to reply. Log in or register to join the conversation.

Post reply Preview Save draft