[Home](https://servhidden.com/) / [Privacy Hosting Guides](https://servhidden.com/guides) / VPS Backup Strategy: Encrypted, Off-Site and Actually Restorable Operations # VPS Backups That Actually Restore No-KYC hosting removes the safety net along with the paperwork: no backups retained, data destroyed within 24 hours of termination, and no support path that ends in a recovered copy. This is the working plan — what to copy, where to put it, how to stop an attacker deleting it, and how to prove it restores. [Read the guide](#guide-body) [FAQ](#guide-faq) ## On this page - [Guide](#guide-body) - [FAQ](#guide-faq) - [Related guides](#guide-related) - [Recommended pages](#guide-cta) No KYC Crypto Only No Logs DMCA Ignored Full Root NVMe SSD 17 min read Updated Aug 2026 On this page [01What actually destroys servers](#what-actually-destroys-servers) [02A snapshot is not a backup, and your host is not one either](#a-snapshot-is-not-a-backup-and-your-host-is-not-one-either) [033-2-1, rewritten for people who never showed ID](#3-2-1-rewritten-for-people-who-never-showed-id) [04Push, pull, and the mistake that lets one bad night eat both copies](#push-pull-and-the-mistake-that-lets-one-bad-night-eat-both-c) [05Encrypt at the source, then decide who holds the key](#encrypt-at-the-source-then-decide-who-holds-the-key) [06Choosing a tool, in one table](#choosing-a-tool-in-one-table) [07Anything that is running is not a file](#anything-that-is-running-is-not-a-file) [08What to back up, and the parts everyone forgets](#what-to-back-up-and-the-parts-everyone-forgets) [09A restore you have not tested is a rumour](#a-restore-you-have-not-tested-is-a-rumour) [10Automating it so it keeps happening](#automating-it-so-it-keeps-happening) [11The short version](#the-short-version) [FAQCommon questions](#guide-faq) [→Recommended pages](#guide-cta) A backup strategy is never tested on the night the server dies. It is tested weeks earlier, in three quiet decisions nobody writes down: where the copy goes, who is allowed to delete it, and whether anyone has ever actually read one back. Hosting that never asked for your identity gives something up in exchange, and this is the honest place to say it. There is no account manager to call, no ticket that resurrects a wiped volume, and [our own retention policy](https://servhidden.com/privacy) is blunt about the reason: server data is destroyed within 24 hours of termination, disks are cryptographically wiped rather than formatted, and **no backups are retained**. That is the same property that makes the platform worth buying, seen from the other side. Anything you would want back after a bad night has to already be somewhere else, and you are the one who puts it there. ## What actually destroys servers Almost nobody loses a server the way they imagine. Catastrophic hardware failure is real but rare, and it is the one case a competent host already engineers against. The losses that actually happen are duller, and each one defeats a different kind of copy — which is why "I have a backup" is not an answer until you say which of these it survives. | What goes wrong | How it usually happens | What gets you back | | --- | --- | --- | | **Your own hand** | An rm -rf where a shell variable was empty, a migration pointed at production, a deploy that dropped the wrong table | Any off-box copy from *before* the mistake — which means retention has to reach back further than the time it takes you to notice | | **Quiet corruption** | A dying NVMe, a truncated write during a reboot, a database that has been writing damaged rows for a week | Versioned copies deep enough to reach a known-good point. A single mirrored copy faithfully mirrors the damage | | **Compromise** | A stolen key, an unpatched application, a poisoned dependency — and then, deliberately, your backups | A copy the compromised machine had no power to delete. Nothing else counts here | | **A provider or country event** | Hardware loss, a legal action at the datacentre, an account or token you can no longer reach | A copy that is not at that provider and not under that jurisdiction | | **Losing the key** | A forgotten passphrase, a keyfile wiped with the server it protected, a LUKS header nobody exported | **Nothing.** This is the only row with no recovery column, and it is more common than hardware failure | Read that table as a checklist rather than a list of fears. A nightly copy to a second disk in the same machine answers row one and nothing else. A snapshot in the same panel answers rows one and two. Only a copy held somewhere the server cannot reach, under a key you still have, answers all five. A backup target needs disk and an address, not cores. The cheapest second machine in a different jurisdiction is a competent endpoint — and the only copy that survives an event at the first provider. ## A snapshot is not a backup, and your host is not one either Snapshots are excellent at what they do: they roll back an upgrade that went wrong, in seconds, with no transfer. What they cannot do is survive the thing that took the server, because they share every failure domain with it — the same provider, the same account, the same billing token, the same country, often the same storage cluster. A snapshot protects you against *yourself*. A backup protects you against everything else. The distinction matters more here than at a mainstream host, because the usual safety nets were removed on purpose. Nobody logs into customer servers, so nobody notices that your backup job has been failing since March. There is no identity attached to the account, so there is no human path to "prove who you are and we will restore it". And termination is genuinely terminal: an expired balance is a data-loss event, not a billing event. **The 24-hour clause is the whole argument.** On this platform a terminated server's data is destroyed within a day, and the disks are cryptographically wiped rather than formatted. There is no undelete, no quiet cold-storage tier, no support outcome that ends in "we found an older copy" — because keeping one would mean holding your data after you asked us not to. The safety net and the privacy are the same trade, made once. ## 3-2-1, rewritten for people who never showed ID The classic rule says three copies, on two kinds of media, one of them off-site. It was written for an era of tape and spinning disk, and the media clause has quietly stopped meaning anything: your production disk is NVMe, your backup target's disk is NVMe, and calling that "two media" is a story you tell yourself. The clause worth keeping is the one about distance, and for offshore infrastructure distance is not measured in kilometres. Rewrite it as **three copies, two providers, two jurisdictions**. The failures that take out both copies at once are almost never physical — they are an account you lost access to, a provider that had a bad week, or a legal instrument that lands in one country and has no reach in another. Two servers in the same rack are one copy with extra steps; two servers under the same legal regime are barely better. Our [jurisdiction guide](https://servhidden.com/guides/choosing-an-offshore-jurisdiction) covers how to pick a second one that does not simply mirror the first's exposure. In practice this is cheap. A backup target does not need cores, and it barely needs a network — it needs disk and an address. The smallest [VPS tier](https://servhidden.com/vps) in a different one of our [seven locations](https://servhidden.com/locations) is a competent restic or Borg endpoint, and for archives measured in terabytes a [dedicated box](https://servhidden.com/dedicated) with real drives costs less per terabyte than any object store. Where the data is genuinely large and rarely read, the economics favour bare metal by a wide margin. One thing people get right on production and wrong on the backup target: pay for it the same way. A second server bought with a card in your own name quietly re-attaches the identity you spent effort removing from the first, and it now holds a complete copy of everything on it. If the production box is paid for [in Monero](https://servhidden.com/guides/how-to-pay-for-hosting-with-monero), the backup box deserves the same treatment. The third copy is the one most people skip, and it is the only one immune to every remote failure at once: a disk you physically hold, updated occasionally, kept offline. Once a month is enough for most people. It costs a coffee's worth of attention and it is the copy that survives scenarios the other two share. ## Push, pull, and the mistake that lets one bad night eat both copies Here is the arrangement almost everyone builds first. A job on the production server runs nightly, holds a key or a token for the backup target, connects, and pushes. It works, it is simple, and it has a property that only becomes visible on the worst day of the server's life: **whoever controls the production box also controls the backups.** That is not a hypothetical. Deleting or encrypting the victim's backups before announcing themselves is standard practice for anyone doing this commercially — the credentials are sitting in a cron job or an environment file, and finding them takes about a minute. A copy your attacker can delete is not a second copy. It is a mirror of the first one with a delay. There are two clean fixes, and they compose well with the [basic hardening](https://servhidden.com/guides/first-hour-vps-hardening-checklist) you should already have done. - **Append-only targets.** Both major tools support a mode where a client can add data and cannot remove it. Borg does it by pinning the SSH key on the target to borg serve --append-only; restic does it with a REST server started with --append-only. The production server writes every night and is structurally incapable of destroying history. Pruning old snapshots then happens on the target, in a session the production box cannot start. - **Pull instead of push.** Invert the direction: the backup host connects to production, reads, and stores. Production holds no credentials for the target at all, so there is nothing to steal. Restrict the key it uses on the production side with restrict and a forced command= so a stolen backup key cannot become a shell. Pull is the stronger model and slightly more work to run; append-only is nearly free if you are already using Borg or restic. Either one turns "the attacker deleted my backups" from an outcome into an attempt. If you take one thing from this guide, take this section. ## Encrypt at the source, then decide who holds the key Both serious tools encrypt on the machine being backed up, before anything crosses the network. The target stores blobs it cannot interpret — which is precisely what makes the cross-provider copy safe. Your second host does not need to be trustworthy, or even friendly; it needs to be reachable and to have disk. That single property is what turns "a server in a country I know nothing about" from a risk into infrastructure. This is a different mechanism from encrypting the server's own disk, and the two answer different questions — our guide on [full-disk encryption on a VPS](https://servhidden.com/guides/full-disk-encryption-on-a-vps) works through what disk encryption does and does not protect while the machine is running. Backup encryption is the easier and more valuable of the two, because the threat model is honest: the data is at rest, on hardware you do not control, and the key never goes there. Which moves the entire risk onto key custody. The passphrase is now a single point of total loss, and it is a worse single point than people expect, because losing it is silent — nothing breaks, backups keep running, and you find out at the exact moment you needed them. Three habits fix it: - Keep the passphrase on the server only as a file readable by root alone, referenced with --password-file, so it never appears in a process list or a shell history. - Keep a human-readable copy off every machine involved. Paper in a drawer genuinely beats a password manager that syncs to an account you may also lose access to. - Add a second key to the repository — restic key add, or an exported Borg key — so that one forgotten passphrase is an inconvenience rather than the end of the archive. The rule underneath all three: **if the only copy of the key lives on the machine the backup exists to replace, you do not have a backup.** You have an encrypted pile of blocks and a story about them. ## Choosing a tool, in one table Tool choice matters less than the direction of the connection and the state of your key, which is why it comes sixth rather than first. That said, the differences are real, and picking the wrong shape for the job creates work later. | Tool | Encrypts before it leaves | Deduplicates | Append-only target | Where it fits | | --- | --- | --- | --- | --- | | **restic** | Yes, whole repository | Yes | Yes, via its REST server | The default choice. Speaks SFTP, object storage and its own server, so the target can be almost anything | | **BorgBackup** | Yes, whole repository | Yes, the best of the group | Yes, natively over SSH | One Linux target reached over SSH. Unbeaten when the data is large and repetitive | | **rsync with rotations** | No — the target sees everything | Partial, via hardlinks | No | Mirroring to a machine you fully control, when instant partial restores matter more than privacy | | **rclone** | Only with rclone crypt | No | Depends on the storage provider | Moving an archive that already exists into object storage, or between providers | | **ZFS replication** | Only with an encrypted dataset | Yes, block level | Via snapshot permissions | Replicating between two ZFS machines. Very fast, very rigid about both ends | | **tar with age or GPG** | Yes, if you encrypt the archive | No | Not applicable | Small, occasional, keep-forever archives where simplicity beats efficiency | For a single server, restic to a second VPS is the shortest path to something correct. For a seedbox, a media archive or anything with many similar large files, Borg's deduplication is the difference between a full disk and a comfortable one — the [seedbox guide](https://servhidden.com/guides/seedbox-setup-guide) covers the storage side of that workload in more detail. ## Anything that is running is not a file The most common corrupt backup in the world is a straight file copy of a live database. It completes without an error, it weighs the right amount, and it restores into a table the engine refuses to open. The database was mid-write when the copy passed; what you saved is a photograph of a page being turned. Three ways out, in increasing order of effort. Dump it: mysqldump --single-transaction gives a consistent InnoDB dump without locking writers, and pg_dump does the same for PostgreSQL. Snapshot it: freeze the filesystem or take an LVM or ZFS snapshot, copy from the snapshot, release it — this is how you handle data sets too large to dump nightly. Or stop it: for a small service, two minutes of downtime at 04:00 is a perfectly respectable consistency strategy, and it is the only one with no edge cases. The same logic reaches past databases. A container's writable layer is disposable, but its volumes are not, and neither is the docker compose file and environment beside them — a backup that restores the data but not the definition leaves you reconstructing the stack from memory. Message queues, Redis with persistence enabled, and a mail spool being written by an MTA all deserve the same treatment: quiesce, snapshot, or dump, but never straight-copy and hope. ## What to back up, and the parts everyone forgets Most people back up the obvious payload — the database and the application directory — and rebuild the rest by hand under pressure. The rebuild is where the hours go. A backup that returns you to a working system, rather than to a pile of correct data, includes the boring layer: - /etc in full, plus the systemd units and timers you wrote, and any crontabs that live outside it. - TLS certificates and their private keys, or at minimum the ACME account key, so certificates renew rather than restart from zero. - Firewall rules and the package list, which together reconstruct the machine's shape faster than any memory of it. - Application secrets and environment files — the ones deliberately excluded from your code repository, and therefore present nowhere else. - DNS records exported as text, including reverse-DNS and PTR entries, which live at the provider and not on the server. **Some keys are not data — they are identity.** A Tor onion service's private key *is* the address: lose it and the site cannot come back at the same [.onion name](https://servhidden.com/guides/how-to-host-a-tor-hidden-service), no matter what else you restored. A WireGuard server key means reissuing every client configuration you ever handed out. A mail server's DKIM key means a new selector and a fresh start on [deliverability](https://servhidden.com/guides/offshore-mail-server-setup). A Lightning node's seed and channel state can mean funds, not files — the [node hosting guide](https://servhidden.com/guides/crypto-node-hosting-guide) is explicit about that. Copy these separately, keep them offline, and treat them as more valuable than the data they protect. ## A restore you have not tested is a rumour Backup software reports on itself, and it reports honestly about the wrong thing. "Snapshot completed" means data was written to a repository. It says nothing about whether the repository can be read on a machine that is not this one, by a person who does not remember what they configured eleven months ago. Start with the cheap integrity checks — restic check --read-data-subset=5% or borg check --verify-data on a schedule — and understand that they verify the archive, not your ability to use it. The real drill is different and takes an afternoon, once. Order a fresh server by the hour in a location you do not otherwise use. Restore onto it with nothing but the repository address, the passphrase, and your own notes. Bring the service up. Time the whole thing. Then destroy the machine. Total cost: a few dollars, and it is the only exercise that produces a number you can trust. What it reliably exposes is never the data. It is the missing package nobody wrote down, the config that lived outside the backed-up paths, the passphrase that only ever existed in the shell history of the server you are trying to replace, and the tool version that reads your repository format. Every one of those is trivial to fix in advance and miserable to discover during an outage. Write down the two numbers the drill gives you: how long a restore took, and how much work the schedule can lose. Those are the backup policy. Everything above is implementation detail in service of them. ## Automating it so it keeps happening Run the job from a systemd timer rather than cron. You get logs in one place, a real record of the last run, and a schedule that survives reboots — none of which cron gives you without extra work. Keep the passphrase out of the unit file itself, which anyone with shell access can read straight out of systemctl cat. Then solve the failure mode that actually gets people, which is not an error but silence. A backup that stopped running six weeks ago looks exactly like one that ran perfectly, because both produce no output. **Alert on absence, not on failure.** Have the job ping a monitor on success and let the monitor complain when the ping does not arrive — and put that monitor anywhere except the server it watches, since a box that is down cannot report that it is down. Set retention deliberately rather than by default. Something like --keep-daily 7 --keep-weekly 4 --keep-monthly 6 covers the mistakes you notice tonight and the corruption you notice in spring, without growing forever. Run the pruning on the target side if you have gone append-only, which is the point of having gone append-only. Transfer volume is rarely the constraint on our network — bandwidth is unmetered on every plan — so schedule for consistency rather than for a quota, and check the timing against your own quiet hours. The wider habits around all of this are covered in the [server OpSec guide](https://servhidden.com/guides/server-opsec-staying-anonymous). ## The short version If you do nothing else with this page, do these six things, roughly in this order: - Put one copy at a second provider, in a second jurisdiction, paid for the same private way as the first. - Make that copy append-only, or pull it from the target, so a compromised server cannot destroy it. - Let the tool encrypt at the source, and keep the key off both machines involved. - Dump databases and stop or snapshot anything that is running; never straight-copy live state. - Back up the identity keys separately — onion, WireGuard, DKIM, node seeds — because those cannot be regenerated. - Restore onto a throwaway server once, time it, and write down what was missing. None of this is exotic, and none of it takes a weekend. It is an afternoon of setup and one drill, against a category of loss that ends projects. On a platform that deliberately keeps nothing about you, the copy you made yourself is the only one that exists — which is the cost of the arrangement, and a fair one. [Spin up a second server](https://servhidden.com/vps) in a jurisdiction that is not your first, and give tonight's backup somewhere to land. FAQ ## VPS backups — common questions ### 01 Does ServHidden back up my VPS? No, and that is deliberate rather than an omission. Our retention policy states that no backups are retained, that server data is destroyed within 24 hours of termination, and that disks are cryptographically wiped rather than formatted. Holding a copy of your data after you asked us to remove it would contradict the reason the platform exists. Everything you want to survive the server has to be copied off it by you, ideally to a second provider in a second jurisdiction. ### 02 Is a snapshot the same as a backup? No. A snapshot shares every failure domain with the server it came from — the same provider, the same account, the same country, often the same storage. It is excellent for undoing an upgrade that went wrong and useless against the loss of the account, the provider or the machine. Treat snapshots as an undo button and backups as insurance; they solve different problems and you want both. ### 03 restic or BorgBackup — which should I use? restic if the target might be object storage, SFTP or something you have not chosen yet, because it speaks the most back ends. BorgBackup if the target is one Linux machine reached over SSH and the data is large and repetitive, because its deduplication is the strongest of the group. Both encrypt on the source before anything leaves the machine, and both support an append-only target, which matters far more than the choice between them. ### 04 How do I stop an attacker from deleting my backups? Remove the ability rather than the motive. Either make the target append-only, so the credentials on the production server can add data but never remove it, or invert the connection so the backup host pulls from production and the production server holds no credentials at all. Deleting backups before announcing themselves is standard practice for anyone doing this commercially, and a copy your attacker can delete is not a second copy. ### 05 Where should the second copy live? At a different provider, in a different jurisdiction, and paid for as privately as your production server. The events that take out both copies at once are rarely physical — they are a lost account, a provider having a bad week, or a legal instrument that reaches one country and not another. Two servers in the same rack are one copy with extra steps. Because the tools encrypt at the source, the second host does not have to be one you trust. ### 06 How often should I back up? Work backwards from how much work you are willing to redo. A blog can lose a day without anyone noticing; a store cannot lose an hour of orders. Nightly is the right default for most single-server setups, with database dumps more often if writes are valuable. What matters more than frequency is retention depth: corruption is often noticed weeks late, so keep enough history to reach a point before it started. ### 07 Is an encrypted backup safe on a server I do not control? For the contents, yes — restic and Borg encrypt before data leaves the source, so the target stores blobs it cannot read and the key never travels. What the target does learn is metadata: roughly how much data you hold, how it changes, and when your jobs run. That is usually acceptable. If it is not, vary the schedule and keep the repository on a machine whose ownership is not linked to the production one. ### 08 What happens if I lose the backup passphrase? The archive is gone, permanently, with no recourse from anyone. This is the most common total loss in the whole subject and the only failure with no recovery path. Keep the passphrase somewhere off every machine involved, prefer paper over an account you might also lose, and add a second key to the repository so one forgotten password is an inconvenience rather than the end of the archive. Related guides ## Keep reading [### How to Choose an Offshore Hosting Jurisdiction in 2026 Buying A practical decision framework for picking an offshore jurisdiction: data-retention law, MLAT exposure, DMCA stance, court speed and real-world enforcement — country by country. 6-question FAQ](https://servhidden.com/guides/choosing-an-offshore-jurisdiction) [### VPS vs Dedicated Server for Privacy-Critical Workloads Buying When a VPS is fine, when shared tenancy is a liability, and when bare metal is the only honest answer. Hardware isolation, hypervisor risk, and cost vs threat model. 6-question FAQ](https://servhidden.com/guides/vps-vs-dedicated-for-privacy) [### Self-Hosted VPN on a No-KYC VPS: WireGuard vs OpenVPN Operations Why a self-hosted VPN beats commercial providers, and how WireGuard and OpenVPN really compare on privacy, performance and operational risk in 2026. 6-question FAQ](https://servhidden.com/guides/self-hosted-vpn-wireguard-vs-openvpn) [### RTX 4090 vs H100 SXM5 for AI Inference (and Where the RTX 5090 Fits) Buying Buying guide: which NVIDIA GPU for self-hosted LLM, image, video, speech, and fine-tuning workloads in 2026. RTX 4090 vs RTX 5090 vs H100 SXM5 vs dual H100 — VRAM, throughput, $/token, when each wins. 6-question FAQ](https://servhidden.com/guides/rtx-4090-vs-h100-for-ai-inference) [### Offshore Windows RDP for MT4 / MT5 / cTrader Forex Trading Operations Complete guide: why a Windows RDP for Forex trading, how to choose a low-latency offshore jurisdiction, MT4 / MT5 / cTrader / Expert Advisor setup, latency to broker servers, and the no-KYC checkout path. 6-question FAQ](https://servhidden.com/guides/offshore-windows-rdp-for-forex-trading) [### DMCA-Ignored Hosting Explained: What It Really Means in 2026 Buying What "DMCA ignored" hosting genuinely buys you, which jurisdictions actually back it up, the workloads that need it, and the copyright traps the term doesn't cover. 6-question FAQ](https://servhidden.com/guides/dmca-ignored-hosting-explained) [### Anonymous Domain Registration with Crypto: WHOIS Privacy in 2026 Privacy A practical 2026 guide to registering domains without revealing your identity: WHOIS regimes by TLD, registrar choice, crypto payment options, and the operational mistakes that leak you anyway. 6-question FAQ](https://servhidden.com/guides/anonymous-domain-registration-with-crypto) [### Crypto Payments for Hosting: Monero vs Bitcoin vs USDT Privacy How payment coin affects what your host learns about you. Privacy, fees, finality and chain analysis exposure for XMR, BTC and USDT — with a clear recommendation. 6-question FAQ](https://servhidden.com/guides/crypto-payments-monero-vs-bitcoin-vs-usdt) [### Is Offshore Hosting Truly Anonymous? An Honest Answer Privacy Offshore, no-KYC hosting removes the identity a normal host collects — but "anonymous" depends on payment, provider logging and your own opsec. Here is what is really traceable. 6-question FAQ](https://servhidden.com/guides/is-offshore-hosting-truly-anonymous) [### The First Hour of VPS Hardening: A Checklist Operations A concrete, ordered checklist to secure a new VPS in under an hour: SSH keys, a firewall, fail2ban, automatic updates, and the attack-surface reduction that stops most opportunistic attacks. 6-question FAQ](https://servhidden.com/guides/first-hour-vps-hardening-checklist) [### What Is No-KYC Hosting? Definition, Legality & How It Works Privacy No-KYC hosting lets you rent a server with zero identity verification — no name, no email, no ID. Here is exactly what it means, how it works technically, whether it is legal, and how to pick a genuine provider. 6-question FAQ](https://servhidden.com/guides/what-is-no-kyc-hosting) [### Is Offshore Hosting Legal? The Honest 2026 Answer Buying Offshore hosting is legal — for you and for the provider. Here is what the term really means, where the legal line actually sits, the myths worth dropping, and how to use it responsibly. 6-question FAQ](https://servhidden.com/guides/is-offshore-hosting-legal) [### How to Pay for Hosting with Monero (XMR) — Step by Step Privacy A step-by-step guide to paying for a VPS or dedicated server with Monero (XMR): why XMR is the most private option, how to get it, and how the checkout works — from invoice to a running server in minutes. 6-question FAQ](https://servhidden.com/guides/how-to-pay-for-hosting-with-monero) [### How to Host a Website Anonymously — A Practical 2026 Guide Privacy A practical, layered guide to hosting a website with no identity attached: the account, the payment, the domain, the jurisdiction, your connection and the content — each layer explained. 6-question FAQ](https://servhidden.com/guides/how-to-host-a-website-anonymously) [### How to Set Up a WireGuard VPN on a VPS — Step-by-Step Guide Operations Build your own private VPN on a VPS with WireGuard: why a self-hosted VPN beats a commercial one, the full setup from install to a connected client, and how to harden it. 6-question FAQ](https://servhidden.com/guides/how-to-set-up-wireguard-vpn-on-a-vps) [### How to Self-Host an LLM on a GPU Server — 2026 Guide Operations Run your own large language model on a rented GPU server: why self-hosting beats an API, which GPU and model to choose, the setup with Ollama or vLLM, and what it costs. 6-question FAQ](https://servhidden.com/guides/self-host-an-llm-on-a-gpu-server) [### Bulletproof Hosting vs Offshore Hosting — What Is the Difference? Buying Bulletproof hosting and offshore hosting are constantly confused — and they are not the same thing. Here is the real difference, why it matters, and which one you actually want. 6-question FAQ](https://servhidden.com/guides/bulletproof-vs-offshore-hosting) [### How to Buy a VPS with Bitcoin — Step-by-Step (2026) Buying A beginner-friendly walkthrough of buying a VPS with Bitcoin: getting BTC, choosing a plan, paying the invoice, and what you get — a running server with no card and no name attached. 6-question FAQ](https://servhidden.com/guides/how-to-buy-a-vps-with-bitcoin) [### Best Countries for DMCA-Ignored Hosting in 2026 Buying Where to host when you want servers beyond the easy reach of US-style takedowns: the jurisdictions that work, what DMCA-ignored really means, and how to choose. 6-question FAQ](https://servhidden.com/guides/best-countries-for-dmca-ignored-hosting) [### How to Host a Tor Hidden Service (.onion Site) — 2026 Guide Operations Set up a Tor onion service on a VPS: what a hidden service is, why it is the strongest form of anonymous hosting, the full setup, and how to keep it actually anonymous. 6-question FAQ](https://servhidden.com/guides/how-to-host-a-tor-hidden-service) [### Offshore Mail Server Setup — Self-Host Private Email in 2026 Operations Run your own private email server on an offshore VPS: why self-host email, what you need, the realistic setup with an all-in-one mail stack, and how to get deliverability right. 6-question FAQ](https://servhidden.com/guides/offshore-mail-server-setup) [### Crypto Node Hosting Guide — Run a Blockchain Node on a VPS Operations How to host a blockchain node on a server: why run your own node, sizing the server for Bitcoin, Ethereum, Monero and more, the setup, and keeping it private. 6-question FAQ](https://servhidden.com/guides/crypto-node-hosting-guide) [### GPU Hosting for Stable Diffusion — Run Your Own Image Server Operations Run Stable Diffusion on your own GPU server: why self-host image generation, which GPU to pick, the setup with a web UI, and what it costs versus a hosted service. 6-question FAQ](https://servhidden.com/guides/gpu-hosting-for-stable-diffusion) [### Server OpSec — Staying Anonymous When You Run a Server Privacy Operational security for anyone running an anonymous server: the mistakes that deanonymise people, the habits that prevent them, and how to keep identities truly separate. 6-question FAQ](https://servhidden.com/guides/server-opsec-staying-anonymous) [### Seedbox Setup Guide — Build Your Own Private Seedbox in 2026 Operations How to build your own seedbox on a server: what a seedbox is, sizing it, installing a torrent client with a web UI, and keeping it private and secure. 6-question FAQ](https://servhidden.com/guides/seedbox-setup-guide) [### How to Bypass DPI Censorship with Your Own VPS (2026 Guide) Privacy Your VPN stopped working? How to bypass DPI censorship with your own VPS: what deep packet inspection actually detects, which of the five 2026 protocols beats which block, and a full VLESS+REALITY walkthrough. 6-question FAQ](https://servhidden.com/guides/bypass-dpi-censorship-with-your-own-vps) [### Full-Disk Encryption on a VPS: LUKS Setup and What It Really Protects Operations How to encrypt a VPS with LUKS: encrypted data volumes, full-root encryption with remote unlock over SSH, the settings that matter on a small server, and an honest account of what disk encryption stops. 8-question FAQ](https://servhidden.com/guides/full-disk-encryption-on-a-vps) [### Hiding Your Origin Server IP: CDNs, Reverse Proxies and What Still Leaks Privacy Whether to put a CDN in front of an offshore server: what it hides, the abuse desk you inherit, the six ways an origin IP leaks anyway, and how to audit yours. 8-question FAQ](https://servhidden.com/guides/hiding-your-origin-server-ip) [### Self-Hosting Matrix: Federation, Metadata and What E2EE Doesn’t Hide Operations What a Matrix homeserver really gives you: Synapse vs Conduit, the server_name you can never change, media that eats the disk, and what federation still reveals. 8-question FAQ](https://servhidden.com/guides/self-host-a-matrix-server) [### How to Migrate a Website to Offshore Hosting Without Downtime Operations The order that makes a host migration boring: lower the DNS TTL days ahead, run both servers in parallel, freeze writes for minutes rather than hours — and clean up the passive-DNS, Certificate Transparency and WHOIS trail the move leaves behind. 8-question FAQ](https://servhidden.com/guides/migrate-website-to-offshore-hosting) [### How to Self-Host a Crypto Payment Gateway with BTCPay Server Operations Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out. 8-question FAQ](https://servhidden.com/guides/self-host-a-crypto-payment-gateway) ## Give tonight’s backup somewhere to land Seven jurisdictions, unmetered bandwidth on every plan, and servers from $7.50/mo that make competent restic or Borg endpoints. No KYC, no email, crypto only — for the backup target as much as for production. [View VPS Plans](https://servhidden.com/vps) [Dedicated Servers](https://servhidden.com/dedicated) [All Locations](https://servhidden.com/locations) ## Structured data (JSON-LD) ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://servhidden.com/#organization", "name": "ServHidden", "url": "https://servhidden.com", "description": "Offshore VPS & dedicated servers in 7 offshore jurisdictions. No KYC, no logs, crypto only. Privacy by architecture.", "logo": { "@type": "ImageObject", "url": "https://servhidden.com/ServHidden.webp", "width": 512, "height": 512 }, "foundingDate": "2025", "areaServed": [ { "@type": "Country", "name": "Iceland" }, { "@type": "Country", "name": "Panama" }, { "@type": "Country", "name": "Moldova" }, { "@type": "Country", "name": "Romania" }, { "@type": "Country", "name": "Switzerland" }, { "@type": "Country", "name": "Netherlands" }, { "@type": "Country", "name": "Russia" } ], "knowsAbout": [ "Offshore hosting", "Offshore VPS", "Bare-metal dedicated servers", "DMCA-ignored hosting", "No KYC hosting", "Cryptocurrency payments", "Privacy engineering", "Token-based authentication", "Anonymous domain name registration", "No-KYC domain registrar", "WHOIS privacy", "Cheap .com domains", "Crypto-paid domain names", "NVIDIA GPU compute", "Windows RDP hosting", "Agentic commerce" ], "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "url": "https://servhidden.com/contact", "availableLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] }, "sameAs": [ "https://servhidden.com/canary", "https://servhidden.com/press" ] } ``` ```json { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://servhidden.com/#website", "url": "https://servhidden.com", "name": "ServHidden", "publisher": { "@id": "https://servhidden.com/#organization" }, "inLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "VPS Backup Strategy: Encrypted, Off-Site and Actually Restorable", "description": "Your host keeps no backups. What really destroys servers, why push backups die with them, restic vs Borg, the keys everyone forgets, and how to test a restore.", "image": "https://servhidden.com/assets/img/guides/vps-backup-strategy.webp?v=1787218773", "author": { "@type": "Organization", "@id": "https://servhidden.com/#editorial", "name": "ServHidden Editorial", "url": "https://servhidden.com/about", "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.", "knowsAbout": [ "Offshore hosting jurisdictions", "Data retention law", "MLAT and judicial cooperation", "WireGuard and OpenVPN deployment", "Tor relay operation", "Monero and Bitcoin payment privacy", "KVM virtualization and bare-metal hosting", "DMCA-ignored hosting" ], "parentOrganization": { "@id": "https://servhidden.com/#organization" } }, "publisher": { "@id": "https://servhidden.com/#organization" }, "datePublished": "2026-08-20T00:00:00+00:00", "dateModified": "2026-08-20T00:00:00+00:00", "mainEntityOfPage": "https://servhidden.com/guides/vps-backup-strategy", "inLanguage": "en", "keywords": "VPS backup, encrypted VPS backup, restic vs BorgBackup, off-site backup VPS, 3-2-1 backup rule, append-only backup, backup a no-KYC server, test a restore", "articleSection": "Operations", "wordCount": 3356 } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Does ServHidden back up my VPS?", "acceptedAnswer": { "@type": "Answer", "text": "No, and that is deliberate rather than an omission. Our retention policy states that no backups are retained, that server data is destroyed within 24 hours of termination, and that disks are cryptographically wiped rather than formatted. Holding a copy of your data after you asked us to remove it would contradict the reason the platform exists. Everything you want to survive the server has to be copied off it by you, ideally to a second provider in a second jurisdiction." } }, { "@type": "Question", "name": "Is a snapshot the same as a backup?", "acceptedAnswer": { "@type": "Answer", "text": "No. A snapshot shares every failure domain with the server it came from — the same provider, the same account, the same country, often the same storage. It is excellent for undoing an upgrade that went wrong and useless against the loss of the account, the provider or the machine. Treat snapshots as an undo button and backups as insurance; they solve different problems and you want both." } }, { "@type": "Question", "name": "restic or BorgBackup — which should I use?", "acceptedAnswer": { "@type": "Answer", "text": "restic if the target might be object storage, SFTP or something you have not chosen yet, because it speaks the most back ends. BorgBackup if the target is one Linux machine reached over SSH and the data is large and repetitive, because its deduplication is the strongest of the group. Both encrypt on the source before anything leaves the machine, and both support an append-only target, which matters far more than the choice between them." } }, { "@type": "Question", "name": "How do I stop an attacker from deleting my backups?", "acceptedAnswer": { "@type": "Answer", "text": "Remove the ability rather than the motive. Either make the target append-only, so the credentials on the production server can add data but never remove it, or invert the connection so the backup host pulls from production and the production server holds no credentials at all. Deleting backups before announcing themselves is standard practice for anyone doing this commercially, and a copy your attacker can delete is not a second copy." } }, { "@type": "Question", "name": "Where should the second copy live?", "acceptedAnswer": { "@type": "Answer", "text": "At a different provider, in a different jurisdiction, and paid for as privately as your production server. The events that take out both copies at once are rarely physical — they are a lost account, a provider having a bad week, or a legal instrument that reaches one country and not another. Two servers in the same rack are one copy with extra steps. Because the tools encrypt at the source, the second host does not have to be one you trust." } }, { "@type": "Question", "name": "How often should I back up?", "acceptedAnswer": { "@type": "Answer", "text": "Work backwards from how much work you are willing to redo. A blog can lose a day without anyone noticing; a store cannot lose an hour of orders. Nightly is the right default for most single-server setups, with database dumps more often if writes are valuable. What matters more than frequency is retention depth: corruption is often noticed weeks late, so keep enough history to reach a point before it started." } }, { "@type": "Question", "name": "Is an encrypted backup safe on a server I do not control?", "acceptedAnswer": { "@type": "Answer", "text": "For the contents, yes — restic and Borg encrypt before data leaves the source, so the target stores blobs it cannot read and the key never travels. What the target does learn is metadata: roughly how much data you hold, how it changes, and when your jobs run. That is usually acceptable. If it is not, vary the schedule and keep the repository on a machine whose ownership is not linked to the production one." } }, { "@type": "Question", "name": "What happens if I lose the backup passphrase?", "acceptedAnswer": { "@type": "Answer", "text": "The archive is gone, permanently, with no recourse from anyone. This is the most common total loss in the whole subject and the only failure with no recovery path. Keep the passphrase somewhere off every machine involved, prefer paper over an account you might also lose, and add a second key to the repository so one forgotten password is an inconvenience rather than the end of the archive." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://servhidden.com/" }, { "@type": "ListItem", "position": 2, "name": "Privacy Hosting Guides", "item": "https://servhidden.com/guides" }, { "@type": "ListItem", "position": 3, "name": "VPS Backup Strategy: Encrypted, Off-Site and Actually Restorable", "item": "https://servhidden.com/guides/vps-backup-strategy" } ] } ```