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!

 

[Peter Downes]

My Server Support has mounted an SSHFS filesystem at /mnt/storagebox/backup/ and I can see via Filezilla some files have been successfully posted to the correct Hetzner storage box back up directory.

Support are not sure of the next steps which I guess is what's the correct way to configure this as Plesk's backup repository? Via the command line?

Thank you.

 

[Maarten]

The DUMP_D path in /etc/psa/psa.conf has to point to the new location, and sw-cp-server needs to be restarted afterwards.
I wrote a small script to handle this, because the Plesk Migrator can’t work with the new location due to the “wrong” ownership of the mounted storage.

So, before migrating to the server, run this script to switch DUMP_D back to the default path (/var/lib/psa/dumps).
After the migration is finished, run it again to switch DUMP_D back to the storage box.

#!/bin/bash

# Configuration
PSA_CONF="/etc/psa/psa.conf"
PSA_CONF_STORAGE="/etc/psa/psa.conf.storage"
PSA_CONF_DEFAULT="/etc/psa/psa.conf.default"
PSA_BACKUP="/etc/psa/psa.conf-$(date +%Y%m%d)"
STORAGE_PATH="/mnt/storagebox/backup/psa/dumps"
DEFAULT_PATH="/var/lib/psa/dumps"

# Create initial backup if it does not exist yet
if [ ! -f "$PSA_BACKUP" ]; then
    cp "$PSA_CONF" "$PSA_BACKUP"
    echo "Backup created: $PSA_BACKUP"
fi

# Determine current DUMP_D location
current_location=$(grep "^DUMP_D" "$PSA_CONF" | cut -d' ' -f2)

# Create config files for both locations if they do not exist yet
if [ ! -f "$PSA_CONF_STORAGE" ]; then
    cp "$PSA_CONF" "$PSA_CONF_STORAGE"
    sed -i "s|^DUMP_D.*|DUMP_D $STORAGE_PATH|" "$PSA_CONF_STORAGE"
    echo "Storage config created: $PSA_CONF_STORAGE"
fi

if [ ! -f "$PSA_CONF_DEFAULT" ]; then
    cp "$PSA_CONF" "$PSA_CONF_DEFAULT"
    sed -i "s|^DUMP_D.*|DUMP_D $DEFAULT_PATH|" "$PSA_CONF_DEFAULT"
    echo "Default config created: $PSA_CONF_DEFAULT"
fi

# Switch between configurations
if [ "$current_location" = "$STORAGE_PATH" ]; then
    cp "$PSA_CONF_DEFAULT" "$PSA_CONF"
    new_location="$DEFAULT_PATH"
    echo "Switched to default location: $DEFAULT_PATH"
else
    cp "$PSA_CONF_STORAGE" "$PSA_CONF"
    new_location="$STORAGE_PATH"
    echo "Switched to storage location: $STORAGE_PATH"
fi

# Restart Plesk
service sw-cp-server restart
echo "Plesk has been restarted"

# Show the effective DUMP_D setting
echo -e "\nChecking current DUMP_D setting:"
grep "^DUMP_D" "$PSA_CONF"

 

[Peter Downes]

Perfect - thank you! Really appreciate you sharing this @Maarten and explaining the logic behind it.

Exactly what I needed!