OVHcloud VPS backup incidents: 2+ months unresolved, 5h outage, tickets closed as resolved

Comments

• rdes Member

  June 19

  How many millions lost?
• plumberg Veteran, Megathread Squad

  June 19

  Thank you gpt
• fredo1664 Member

  June 19

  Welcome to LET, thank you SO much for using this community to put pressure on a provider with no intention whatsoever to participate in the community. Extra points for, on top of this, the AI slop.
  Please note, however, that a post on this community has no impact at all on OVH.

  Thanked by 3tentor mrerenk buggedout
• Lex Member

  June 19

  4 tickets with serious issues and you're still with this provider? That's 100% on you.

  I'm out by the first ticket if they're deflecting/not solving anything and by the third ticket if they solve shit but new shit keeps happening.

  First time it happens, shame on them. Second time it happens, same on you.
• jobayer Member

  June 19

  **libvirt was killed and the VPS rebooted after abortSnapshot cancelled the backup.
  **
  As per this statement the vps rebooted after failure.

  So did you check whether the server actually boot successfully after the reboot? If the VPS started successfully but your web services did not start that would be a different issue. You can use third party uptime checker or run your own uptime checker from another server. it will notify you immediately when the site goes down or boot the server via api. Not a solution just a workaround if you dont want to change the provider. Large providers usually dont change system because of a single customers issue. Most of the time it takes multiple reports or a wider impact before it gets enough attention. Also you can migrate to another vps. Libvirt issue can be happened in that server node only due to low memory or others problems. You can try to buy another vps and move data and see if it solve or not.
• ascicode Member

  June 19

  Get a dedi and backup yourself.

  Thanked by 2totally_not_banned tux
• concept Member

  June 19

  If your site is critical, always do your own backups and have redundancy. I would get another vps with another provider/location and create a mirror/backup of your site so if one goes down, the other is up.

  Thanked by 3oloke tux tentor
• totally_not_banned Member

  June 19 edited June 19

  @ascicode said:
  Get a dedi and backup yourself.

  In any case that would improve my sleep quality. Doesn't need a dedi to do that though.
• logisoftpl Member

  June 20

  Thanks for the practical comments. I agree with the main recommendation here: for critical workloads we should not rely on a provider-side VPS backup feature as the only operational safety net. We are preparing provider-independent backups and migration/redundancy.

  A technical clarification: this was not just "the web services did not start after reboot". During the later 2026-06-19 14:55-15:15 UTC incident, independent monitoring from two other servers saw public HTTP checks fail, direct backend checks fail, VPS C TCP/22 fail, and the VPS heartbeat fail. After recovery, guest evidence showed new boot times and systemd had 0 failed units. So the symptom was at least VPS/network/reboot-level, not only Apache/PHP/app startup.

  Current status as of 2026-06-20 morning CEST:

  • the shops are responding again with HTTP 200;
  • CS16036806 is still open;
  • OVH Manager now shows an automatic-backup restore point dated 19 June 2026 23:57, so at least one fresh restore point appeared after the QEMU guest-agent remediation;
  • OVH still has not provided RCA or a durable prevention/migration/credit position.

  So yes: own off-site backups and migration are the practical path. The unresolved part is that OVH has not explained why the earlier backup/snapshot state required abortSnapshot to unblock, nor why another production-impacting reboot/outage happened after the requested QEMU remediation.
• nghialele Member

  June 20

  Have you tried manage backup yourself?
• OhJohn Member

  June 20

  I said again and again here on LET: OVH vps are not ready for production, esp. not the ones in local zones.

  Their dedis are fine but in vps land they still seem to lack the means to master their openstack stack....
• dbadude Member

  June 20

  i think you need to have an SLA contract with support for this. Just regular vps is yolo SLA.
• Levi Member

  June 20

  What is “morning CEST”?
• logisoftpl Member

  June 22

  Small factual update, since OVH has now replied in CS16036806.

  OVH wrote today that their internal team is still investigating, but that their technicians migrated the VPS to another host because the issue appears to be related to the host running the service. They also wrote that after this operation the system successfully performed a backup on 2026-06-21.

  So this now looks much more like a provider-side host/infrastructure issue than only a workload or application issue inside the VPS.

  The ticket is still open. We have asked OVH for the missing parts: the exact time of the host migration, the root cause on the previous host, why recovery on 2026-06-19 required the legacy abortSnapshot API instead of a normal Manager action, why earlier tickets were repeatedly closed as resolved while the same problem was still ongoing, and their refund/service-credit or safe cancellation/migration position.

  We have already moved the most critical shops away from this VPS, so the practical mitigation is in progress. What remains open is the RCA and accountability for the repeated ticket closures and outages.
• logisoftpl Member

  June 24

  Follow-up with the April evidence, because it materially changes the scale of the issue.

  The first major VPS C incident was not a short outage. Our monitoring shows Elektriko / www.elektriko.pl down from 2026-04-15 11:36 UTC until at least 2026-04-16 10:42 UTC, so at least 23h05m.

  The first OVH ticket for this incident was CS15504970. OVH support disclosed the effective recovery path, the legacy API abortSnapshot endpoint, only on 2026-04-16 at 07:28 UTC, almost 20 hours after the first alert.

  That matters because the issue was not just "backup failed". The standard Manager UI did not expose a working abort path for the blocking operation. The same class of backup/snapshot issue then kept recurring across later tickets, while earlier tickets were repeatedly treated as resolved/closed even though the underlying issue was still ongoing.

  OVH's latest CS16036806 response also says the VPS was migrated to another host on 2026-06-20, that host resource saturation plus QEMU guest-agent incompatibility may have caused the freeze, that snapshot abort is currently API-only, and that blocking operations/errors prevented backups from running. That explains the stale 2026-04-14 restore point we were seeing.

  We have moved the critical shops away from this VPS. What remains open is RCA, compensation/service credit, and an explanation for the earlier ticket closures while the same operational problem kept recurring.
• logisoftpl Member

  July 3

  Update 2026-07-03:

  OVHcloud Claims has now confirmed that this was treated as an SLA breach. They applied the maximum contractual SLA credit under their VPS terms: 50% of the monthly service cost for each of April, May and June 2026, i.e. 45 days total.

  We rejected that as a full/final resolution and accepted it only as the undisputed minimum SLA credit.

  The unresolved points remain:

  • no proper provider-side RCA for the recurring automated-backup/snapshot failures;
  • recovery for the blocked operation depended on the old abortSnapshot API instead of a normal OVH Manager control;
  • the first April incident lasted over 23 hours before we learned about that recovery path;
  • earlier related tickets were repeatedly closed/proposed as resolved while the same issue continued;
  • no clear preventive action beyond migrating the VPS host on 2026-06-20 and stating that a later backup existed.

  Ticket CS16036806 is open again. Our critical shops have already been moved away from this VPS; we are keeping VPS C only for lower-priority/legacy cleanup while the complaint remains unresolved.
• logisoftpl Member

  July 7

  Small factual update: OVHcloud Claims has now replied in CS16036806.

  They state that a formal provider-side RCA / post-incident report / post-mortem is not included in the standard support scope for this service. They also offered one additional month of VPS renewal as a goodwill gesture, but only on the condition that accepting it would be a full, final and amicable resolution of CS16036806 and all matters raised in it.

  We rejected that condition. We said we can accept any additional goodwill/service credit only without prejudice and without waiving the unresolved issues: the 23h+ April outage, the legacy API-only recovery path for aborting the blocked snapshot/backup operation, repeated ticket closures while the same issue was recurring, and the lack of a written RCA suitable for our production incident records.

  For context, the business-critical stores affected by this risk and moved away from this VPS include elektriko.pl, hydrauliko.pl and bakaliowo.pl.

  The ticket is open again and we have asked OVHcloud for a final written complaint/claims decision.
• logisoftpl Member

  7:04AM

  Update - 10 July 2026:

  The same automated-backup failure has recurred on vps-66c201a8.vps.ovh.net.

  The daily backup is scheduled for 23:57 UTC. At 01:59:11 CEST the final entry in the previous guest journal was "qemu-ga: guest-fsfreeze called". There was no matching thaw event or orderly guest shutdown. At 07:38 CEST OVH Manager still showed the VPS as "Saving...". The next boot began at 08:00:50 CEST, leaving a confirmed guest telemetry gap of 6h 01m 39s.

  After the reboot the VPS became active again, but the newest visible restore point remained 8 July 2026 23:57. The failed scheduled run did not create a new restore point.

  Services are currently restored. We added the complete evidence to open ticket CS16036806 at 09:02 CEST and requested that OVH prevent another backup execution before the next window, identify the backend task and reboot action, explain why fsfreeze was not followed by thaw, and provide an RCA and prevention plan.

  Given this recurrence, we are migrating the remaining applications away from VPS C. I will update this thread if OVH provides a technical explanation or durable fix.
• daffyy Member

  7:37AM edited 7:42AM

  https://community.ovhcloud.com/t/vps-snapshot-saving-slow-hanging/8414

  https://cloudlinux.zendesk.com/hc/en-us/articles/4408097389714-qemu-guest-agent-calls-fsfreeze-CloudLinux-VM-hangs-on-ProxMox

  https://forum.proxmox.com/threads/backup-crashes-vm-guest-fsfreeze-freeze-failed-got-timeout.104694/page-2

  Check proxmox website because it can be your fault + stop spam in every possible place like Reddit,wht etc...
  Just migrate to other provider or just fix your system.

  So, in case od unmanaged service... just try to find a solution and not only try to show ovh in dark light