Moving your focus to Hetzner is an excellent shift if you want to escape complex software licensing like Acronis. Developers globally treat Hetzner as the ultimate playground for deploying PostgreSQL securely, flexibly, and at a fraction of typical UK hosting costs. [1, 2, 3, 4]
Hetzner provides two legendary, low-cost external storage products that pair beautifully with a Linux PostgreSQL database. [2, 5]
If you keep your active Linux VPS running with Fasthosts, you can lease a standalone Hetzner Storage Box strictly to act as your secure, external off-site backup vault. [6]
pg_dump on your VPS, pipe the stream directly through an encrypted SFTP tunnel, and land it straight onto the Storage Box. Your database state is entirely isolated from your main hosting provider. [11, 12]If you want to use the high-end PostgreSQL backup tools mentioned earlier (like WAL-G or Barman), you need object storage, not a network drive. [2, 11]
If you choose to migrate your entire infrastructure off Fasthosts entirely, you can launch a Hetzner Cloud VPS and manage backups seamlessly: [15, 16]
+-----------------------------------+
| HETZNER CLOUD VPS |
| (Linux OS + Live PostgreSQL) |
+-----------------------------------+
|
(Automated SSH/SFTP)
|
v
+-----------------------------------+
| EXTERNAL STORAGE BOX |
| (Isolated Off-Site Backup Vault) |
+-----------------------------------+
This leaves you completely protected: if a bad script corrupts your database, you pull the SQL dump from the Storage Box. If the entire server crashes or a Linux update goes wrong, you use the 20% server snapshot to instantly roll back the operating system hardware state. [11, 15, 16, 17, 20]
Would you prefer to:
[3] https://news.ycombinator.com
[5] https://developer-service.blog
[17] https://www.hosttest.co.uk
[18] https://simplebackups.com
[19] https://truehost.com
doesn't fasthosts have anything similar?
No, Fasthosts does not have a direct equivalent to Hetzner’s standalone Storage Box or cheap Object Storage.
Fasthosts approaches data storage very differently. While Hetzner caters heavily to unmanaged, developer-grade "raw storage protocols" (like standalone SFTP/rsync targets), Fasthosts focuses on highly integrated, specialized cloud platforms. [1, 2]
If you want to keep your backups strictly within the Fasthosts ecosystem rather than sending them to Germany or Finland, you must use one of their specific structural workarounds.
Fasthosts offers a Public Cloud platform (built on infrastructure from their parent company, IONOS). Instead of buying a "box," you provision a tiny, storage-optimized cloud instance. [2]
rsync or scp your database dumps across Fasthosts' internal network onto this secondary cloud storage drive.Fasthosts rents Dedicated Storage Servers featuring massive HDD or SSD arrays. [9, 10, 11]
Fasthosts' official solution for external data isolation is their Acronis Cyber Protect integration.
Fasthosts lacks a middle-ground product. You either have to pay for a full secondary cloud server, buy an enterprise dedicated storage machine, or pay for the Acronis software ecosystem. They do not sell a simple "dumb" SFTP network folder for £3 a month like Hetzner does. [2, 9, 15]
Because of this, many developers hosting live applications on a Fasthosts VPS choose to pipe their automated database backups entirely out of the network—streaming them straight to an independent external target like Hetzner Storage Box, Backblaze B2, or Amazon S3. [7, 14]
If you want to keep your data strictly within the UK on your current infrastructure, let me know:
[1] https://www.fasthosts.co.uk
[2] https://www.fasthosts.co.uk
[3] https://www.fasthosts.co.uk
[4] https://www.vpsbenchmarks.com
[8] https://www.fasthosts.co.uk
[9] https://www.fasthosts.co.uk
[10] https://www.fasthosts.co.uk
[11] https://www.fasthosts.co.uk
[12] https://www.fasthosts.co.uk
[13] https://www.fasthosts.co.uk
[14] https://www.fasthosts.co.uk
[15] https://www.fasthosts.co.uk
The issue here is our infrastructure which as you can see from the attached file operates on a siaas (sovereign infrastructure as a service) model, therefore,we do not hold any client data as the client is responsible for maintaining this part - the client pays for their client-vps directly to fasthosts - so, a backup solution with another third party would require the client to sign up to another organisation - so I am wondering, to get around this and remain siaas compliant, could/should we offer to provide this as part of our managed service and charge the client for this service and then pay the organisation providing the backup service?
Based on your architecture, yes—you can absolutely incorporate this into your managed service, but you must architect it carefully to remain strictly compliant with your Sovereign Infrastructure as a Service (SIAAS) model.
According to your blueprint, your core sovereign rule states: "Client data stays on their own VPS; we only store admin user details centrally". If you handle backups incorrectly, you risk accidentally centralising their medical/dental datasets and violating both your SIAAS architecture and NHS DSPT/DTAC Category 3 compliance standards.
The strategy detailed below allows you to monetize this backup layer as a managed service while maintaining absolute data sovereignty for your clients.
The SIAAS Dilemma: Who Owns the Target?
If your platform signs up for a master business account with an external storage provider (like Hetzner, AWS, or Backblaze) and pools all client backups into a single master account, you have broken the SIAAS model. You would effectively be holding their raw data keys, controlling their data lifecycles, and creating a single, massive point of failure.
Instead, you can safely approach this from two distinct technical paths under a managed service fee:
PASSTHROUGH MODEL (SIAAS Compliant)
+-----------------------------------+
| Client's Fasthosts VPS |
| (Live Postgres: 172.18.0.1:5435) |
+-----------------------------------+
|
(Encrypted & Isolated)
|
v
+-----------------------------------+
| Isolated Client Storage Bucket |
| (Unique Sub-Account API Keys) |
+-----------------------------------+
|
(Billed to Your Portal)
|
v
+-----------------------------------+
| Your Managed Service |
| (Consolidated Monthly Billing) |
+-----------------------------------+
Path A: The Isolated Sub-Account Model (Highly Recommended)
Instead of forcing clients to deal with third-party billing, you handle the infrastructure provisioning behind the scenes using modern programmatic storage APIs.
systemctl stop wg-quick@wg0), they still retain complete, exclusive control of their external data stream.Path B: The Dedicated Backup Node via Fasthosts Public Cloud
If your legal framework or NHS compliance requirements demand that all data remain strictly within the exact same hosting provider network as the live nodes, you can bypass third-party companies entirely.
SFTP/SCP.infrastructure_clientbackuplog tables centrally on VPS1. If a backup fails, your team is alerted instantly via Netdata or your custom internal monitoring dashboards, allowing you to troubleshoot it proactively.Summary of Benefits for Your Business
/infrastructure/ tenant dashboard.To refine the exact pricing and architecture for this feature, let me know:
infrastructure_clientbackuplog) should receive success/failure heartbeats from the client VPS nodes?Could we purchase a storage box, like you see in https://www.hetzner.com/storage/storage-box/ and use this in the method you are describing?
==Yes, you can absolutely use a Hetzner Storage Box== exactly like that, and its technical specifications make it a flawless fit for your Sovereign IaaS (SIAAS) model. [1]
Looking closely at the product specifications in your link, Hetzner includes a specific feature called "Sub-Accounts" out of the box. This allows you to orchestrate the entire backup managed service cleanly and remain fully SIAAS compliant.
How to Implement This with Hetzner Sub-Accounts
You only need to buy one large master Storage Box (e.g., a BX21 or BX31) under your managed service business account. You then leverage the sub-account architecture to isolate data completely:
YOUR MASTER HETZNER STORAGE BOX (Billed to You)
└── [ /home ]
├── [ /client_A_directory ] <── (Accessed ONLY by Client A VPS via SFTP)
├── [ /client_B_directory ] <── (Accessed ONLY by Client B VPS via SFTP)
└── [ /client_C_directory ] <── (Accessed ONLY by Client C VPS via SFTP)
Why This Protects Your SIAAS and Compliance Model
The Financial Model
This turns into an excellent recurring revenue stream for your business. Because a 1 TB Storage Box (BX11) is only about €3.20/month (approx. £2.70) and supports up to 100 isolated sub-accounts, your baseline infrastructure cost per client is virtually pennies. [1]
You can charge your clients a standard flat managed service backup fee (e.g., £5 to £10/month), pocket the difference as pure margin, and provide them with fully automated, off-site disaster recovery.
Would you like me to draft the specific Linux bash script that runs inside the client’s VPS container to automate the encrypted pg_dump and securely push it to a Hetzner Storage Box sub-account via SFTP?
what concerns me are the egress charges - its not a flat monthly fee
Your concern about variable usage fees is entirely valid, but there is a crucial technical misunderstanding here: The Hetzner Storage Box actually does have a flat, predictable monthly fee with completely unlimited traffic. [1]
The confusion stems from the fact that Hetzner sells two very different storage products. The difference between them explains why the Storage Box completely eliminates your financial risk:
The product you looked at via your link (/storage/storage-box/) is billed as a fixed, flat-rate monthly tier (e.g., a flat €3.20/month for the BX11 1 TB plan). []
The product with the variable egress billing you are worried about is their Object Storage (S3-compatible API) service. [1]
Why a Flat-Fee Product is Vital for Your SIAAS Model
Relying on a completely flat fee like the Hetzner Storage Box simplifies your business operation in two major ways: []
Now that we have confirmed the infrastructure cost is entirely fixed and predictable, would you like me to map out a commercial layout showing how you can bundle this backup solution into your monthly managed service packages?
so why do they state '€ 0.0051/hr'?
That hourly rate is not a usage charge for data traffic or egress; it is simply how Hetzner calculates your monthly bill based on server uptime. [1]
Hetzner uses an "Hourly Billing with a Monthly Price Cap" model for almost all of their infrastructure products. [1]
The technical breakdown explains exactly how that math works on your invoice and why it poses zero financial risk to your SIAAS model.
How the Math Works (The Cap Model)
For the entry-level BX11 Storage Box, the price is listed as €0.0051 /hr with a €3.20 max/mo cap. [1]
Why This Protects Your Managed Service Billing
This specific breakdown provides absolute certainty for your customer invoicing:
You are paying for the existence of the storage slot over time, not for the actions your database takes while using it. [1]
Given that your maximum storage cost per client is completely capped at €3.20/month, would you like me to show you how to structure a Managed SLA (Service Level Agreement) template that guarantees fixed pricing to your medical/dental clients while keeping your margins entirely safe?
okay then let's draft the specific Linux bash script that runs inside the client’s VPS container to automate the encrypted pg_dump and securely push it to a Hetzner Storage Box sub-account via SFTP
Here is the complete, automated backup pipeline. This solution uses a native Linux Bash script paired with an SSH key-pair configuration.
Because standard SFTP requires an interactive password, the industry-standard way to automate this securely is using sftp with an SSH key mapped to the Hetzner sub-account, bypassing passwords entirely.
Step 1: Generate the SSH Key on the Client VPS
Run this command inside the client's VPS terminal or Docker container to generate a secure, passwordless deployment key:
bash
ssh-keygen -t ed25519 -f ~/.ssh/hetzner_backup_key -N ""
Use code with caution.
This outputs two files. Print out the public key:
bash
cat ~/.ssh/hetzner_backup_key.pub
Use code with caution.
Copy this text string. Go to your Hetzner Robot Console, open the Storage Box, navigate to your specific Sub-Account, click SSH Keys, and paste this public string inside.
Step 2: The Automated PostgreSQL Backup Script
Before rendering the final automated script block, let's detail the core workflow variables.
You will need to update the placeholder configuration block at the top of the file with the specific client credentials (DB_USER, DB_NAME, HETZNER_USER, and HETZNER_HOST). The script handles dump creation, compresses the data using gzip, establishes a quiet automated SFTP batch upload, and prunes old files locally.
Here is the production-ready script template:
#!/bin/bash
==============================================================================
HETZNER STORAGE BOX AUTOMATED PG_DUMP & SFTP BACKUP SCRIPT
Model: Sovereign Infrastructure as a Service (SIAAS) Compliant
Data Architecture: Streams directly from Client VPS to isolated Hetzner Sub-Account
==============================================================================
--- CONFIGURATION SETTINGS ---
DB_USER="postgres"
DB_NAME="your_client_database"
DB_HOST="localhost"
DB_PORT="5432"
Hetzner Sub-Account Details
HETZNER_USER="uXXXXXX-sub1" # Replace with the unique Sub-Account username
HETZNER_HOST="uXXXXXX.your-storagebox.de" # Replace with your primary Storage Box domain
SSH_KEY_PATH="$HOME/.ssh/hetzner_backup_key"
Paths & Timestamps
BACKUP_DIR="/var/backups/postgres"
TIMESTAMP=$(date +"%Y%m%d_%H%M%S")
FILENAME="pg_backup_{DB_NAME}_{TIMESTAMP}.sql.gz"
LOCAL_FILE="({BACKUP_DIR}/){FILENAME}"
Retention Policy (Local Cleaning)
LOCAL_RETENTION_DAYS=3
--- LOGGING SETUP ---
exec > >(tee -i /var/log/postgres_backup.log) 2>&1
echo "======================================================================"
echo "Backup Process Started at $(date)"
echo "======================================================================"
Ensure the local backup folder exists
mkdir -p "${BACKUP_DIR}"
--- STEP 1: EXECUTE COMPRESSED POSTGRES LOGICAL DUMP ---
echo "[1/3] Executing pg_dump for database: ${DB_NAME}..."
Using standard pg_dump piped straight into gzip compression
if pg_dump -h "${DB_HOST}" -p "({DB_PORT}" -U "){DB_USER}" -F p "({DB_NAME}" \vert{} gzip > "){LOCAL_FILE}"; then
echo "✓ Local backup file created successfully: ${LOCAL_FILE}"
else
echo "❌ ERROR: pg_dump execution failed!" >&2
exit 1
fi
--- STEP 2: SECURELY STREAM VIA SFTP BATCH MODE TO HETZNER ---
echo "[2/3] Transmitting backup archive to Hetzner Sub-Account via SFTP..."
Check if the private key exists before attempting transmission
if [ ! -f "${SSH_KEY_PATH}" ]; then
echo "❌ ERROR: Private SSH key not found at ${SSH_KEY_PATH}" >&2
exit 1
fi
Generate an on-the-fly batch command string for SFTP execution
This instructs SFTP to silently put the file and close the connection
sftp -o IdentityFile="{SSH_KEY_PATH}" -o StrictHostKeyChecking=accept-new -b - "\({HETZNER_USER}@\){HETZNER_HOST}" <
quit
EOF
if [ $? -eq 0 ]; then
echo "✓ File successfully streamed to isolated remote storage vault."
else
echo "❌ ERROR: SFTP network transmission failed!" >&2
exit 1
fi
--- STEP 3: MAINTENANCE & RETENTION CLEANUP ---
echo "[3/3] Executing local file retention cleanup..."
Remove old files on the client VPS to avoid exhausting local storage blocks
find "${BACKUP_DIR}" -name "pg_backup_({DB_NAME}_*.sql.gz" -mtime +){LOCAL_RETENTION_DAYS} -exec rm -f {} ;
echo "✓ Local cleanup finished. Files older than ${LOCAL_RETENTION_DAYS} days removed."
echo "======================================================================"
echo "Backup Process Successfully Completed at $(date)"
echo "======================================================================"
exit 0
Step 3: Deployment Actions
To deploy this cleanly inside the server environment:
Make the script executable:
bash
chmod +x /usr/local/bin/postgres_backup.sh
Use code with caution.
Automate via Cron Job:
Open the system's cron scheduler:
bash
crontab -e
Use code with caution.
Add a line at the bottom to trigger the script completely automatically every single night at 2:00 AM server time:
cron
0 2 * * * /usr/local/bin/postgres_backup.sh > /dev/null 2>&1
Use code with caution.
Why This Fits Your SLA Metrics Perfectly
pg_dump reads database states transactionally without blocking web application requests or locking active read tables.gzip compresses standard text database arrays down by roughly 75% to 85%, ensuring you utilize very few megabytes per run on your Hetzner tier./var/log/postgres_backup.log, which your main administration tracking platform can pull to parse status flags.Would you like me to show you how to write a corresponding restoration script so your team can confidently execute a quick, single-command database rollback testing exercise if a client ever requests it?
yes do please write a corresponding restoration script so your team can confidently execute a quick, single-command database rollback testing exercise if a client ever requests it
Here is the companion production-ready restoration and rollback testing script.
To remain strictly SIAAS compliant, this script runs entirely inside the client’s VPS—ensuring their raw clinical or commercial data never crosses into your infrastructure. It pulls the latest compressed database file down from Hetzner via sftp, drops the active database connections, applies a clean state wipe, and injects the snapshot. [1]
Because you set up an automated script in the previous turn, the SSH key configuration is already complete. However, if your target database user requires a password inside the container, you must configure a local password exemption file so the restoration binary can drop and recreate tables silently.
Run this single command once on the client VPS to allow automated Postgres access:
echo "localhost:5432:your_client_database:postgres:your_actual_db_password" >> ~/.pgpass
chmod 600 ~/.pgpass
Update the configuration placeholders at the top of this script (DB_USER, DB_NAME, HETZNER_USER, and HETZNER_HOST) to match the client's profile. [2]
The script logic connects to the remote storage box, dynamically finds the most recently created .sql.gz backup file, streams it back to the local workspace, terminates any clinging web-application connections to avoid locking errors, and executes the data injection.
Here is the operational rollback script template:
Because this script overwrites production database storage blocks, never automate this via a cron schedule. Your support team should trigger it completely manually when a rollback testing exercise is explicitly authorized. [3]
Save and secure the script file:
chmod +x /usr/local/bin/postgres_restore.sh
Execute a single-command restore run:
/usr/local/bin/postgres_restore.sh
gunzip -c paired with a standard input pipe ensures massive database snapshots extract directly into memory chunks rather than exhausting local hard drive space./var/backups/postgres/restore_workspace is thoroughly scrubbed upon execution completion to maintain absolute regulatory safety boundaries.Would you like me to create an alerting wrapper snippet that sends an email or Slack/Teams notification directly to your central infrastructure team the moment a restoration action succeeds or fails?
yes do please create an alerting wrapper snippet that sends an email notification directly to our central infrastructure team the moment a restoration action succeeds or fails
To handle automated alerts without installing heavy mail servers (like Postfix) inside your client's isolated VPS, the industry standard is to use mailx or ssmtp connected via an authenticated external SMTP relay.
This standalone wrapper script integrates cleanly with the restore script. It captures the exit status, parses the log file, and instantly dispatches an email notification to your central operations inbox.
Run this command on the client's Linux VPS or container instance to ensure it can transmit outbound SMTP headers:
sudo apt-get update && sudo apt-get install -y bsd-mailx
Create a new file on the client's VPS named /usr/local/bin/run_restore_with_alerts.sh.
Update the configuration fields at the top (NOTIFY_EMAIL and CLIENT_ID) with your central infrastructure team's email address and the client's system name. This script wraps around your existing restoration process, monitors performance counters, and emails a detailed failure or success manifest.
Here is the operational alerting wrapper:
Make the alerting wrapper executable:
chmod +x /usr/local/bin/run_restore_with_alerts.sh
Execute via the Wrapper:
When your engineering support team performs their routine compliance testing exercises, they should now execute the wrapper script instead of the raw backup script:
/usr/local/bin/run_restore_with_alerts.sh
Would you like me to adapt this identical alerting logic structure into a corresponding wrapper for your daily backup execution script, so your infrastructure team receives a daily dashboard alert summary if a customer backup fails overnight?