Question Disaster Recovery Strategy - Remote Backup Storage for Faster Critical Site Restoration

[Peter Downes]

Server operating system version

Operating System: Linux - Almalinux

Plesk version and microupdate number

18.0.4

Our Situation:

We experienced a catastrophic disk hardware failure on our managed dedicated AlmaLinux server (560GB, ~100 WordPress sites and x1 Bespoke PHP website that is 60GB via Plesk Web Host Edition).

The recovery process took:

• 6+ hours of fsck attempts
• 19+ hours for bare-metal restore from R1Soft CDP backup
• Total downtime: 24+ hours

While we have R1Soft daily backups (which saved us), the issue is that all subscriptions were offline until the complete BMR finished.
Some clients needed to be back online much faster than others.


Proposed Short-Term Solution:

We're planning to implement off-site backup storage using Hetzner Storage Box for ~10 critical subscriptions:

1. Configure Hetzner Storage Box as FTP(S) remote storage on primary server
2. Schedule daily Plesk backups of critical subscriptions → Hetzner Storage Box
3. In a disaster scenario: provision secondary VPS with Plesk
4. Configure same Hetzner Storage Box on secondary VPS
5. Restore critical sites from remote backups (estimated 1-5 hours)
6. Update DNS to point to secondary VPS
7. Critical sites online while main BMR continues

Questions for the Community:

1. Is this approach sound? Are we missing anything obvious?
2. Backup scheduling: Should we run local AND remote backups, or just remote to Hetzner? Concerned about resource impact (we've had CPU spike issues).
3. Hetzner Storage Box experience: Anyone using this for Plesk FTP(S) backups? Any gotchas?
4. Restoration process: Can Plesk on secondary server restore subscription backups created on primary server without issues? Any compatibility concerns?
5. Better alternatives: Is there a simpler/better approach we should consider for "critical sites back online quickly" during a full server failure?

Environment:

• Dedicated server, AlmaLinux, Plesk Web Host Edition 18.0.4
• R1Soft CDP for full server backups (daily)
• ~100 WordPress/WooCommerce sites plus x1 Bespoke PHP website that is 60GB
• 10-15 critical e-commerce clients needing priority recovery -
• Total ~ 120GB back up size

Any advice, experiences, or warnings would be greatly appreciated!

 

[Maarten]

Hi,

Your general approach makes sense, especially the idea of having subscription-level backups off-site so you can bring critical clients back online quickly while a full BMR is still running.

A couple of practical tips from experience:

Hetzner Storage Box

• Storage Boxes work well with Plesk, but I would strongly recommend using SSHFS instead of FTP/FTPS.
• SSHFS is generally more stable, performs better with many small files (hello WordPress), and avoids some FTP timeout/connection issues during large backups.
• Hetzner has a clear guide for this setup:
  https://community.hetzner.com/tutorials/setup-autofs-mount-storagebox
  Once mounted, you can just add it as a “local” backup repository in Plesk.
  
  Note:
  Plesk will show a warning about “wrong owner/permissions” on the SSHFS mount. This is a known and harmless warning for SSHFS-mounted storage; it does not prevent backups or restores from working correctly.
  

Reducing backup size & load
To keep backup time, storage usage, and CPU impact down, it’s a good idea to exclude paths that are either cache, logs, or already backup data themselves.

For WordPress-heavy servers, these exclusions help a lot:

**/wp-content/ai1wm-backups/*
**/wp-content/cache/*
**/wp-content/debug.log
**/wp-content/updraft/*
**/wp-content/uploads/backwpup/*
/wordpress-backups/*

This reduces upload time to remote storage significantly and avoids backing up data that can be regenerated or isn’t needed for a restore.

Restoring subscription backups on another Plesk server generally works fine, as long as:

• Plesk version is the same or newer
• Same OS family (which you already plan)
• Required PHP versions/extensions are available

Overall, your “critical sites first” strategy is solid. Mounting the Storage Box via SSHFS and trimming unnecessary data from backups should make it faster and more reliable without adding much complexity.

 

[Maarten]

Hi @Sebahat.hadzhi,
Based on this discussion, I’ve submitted a feature request to Plesk for a Time Machine–like disaster recovery feature (restore a full server to new hardware from an existing backup).

 

[Peter Downes]

Thank you @Maarten for the detailed and practical advice! The SSHFS recommendation makes a lot of sense - better performance and stability is exactly what we need. I hadn’t considered the backup bloat issue either, so those WordPress exclusions will be very helpful.

Really appreciate you sharing the Hetzner guide and the heads-up about the permissions warning. This gives me confidence to move forward with the implementation.

Thanks again for taking the time to share your experience!