How backups actually work here, including what they will not save you from

"Daily backups" is the least useful sentence in hosting. It tells you a job runs. It does not tell you how far back you can go, whether the copy survives the building, or whether anyone has ever restored one.

Here is the actual policy, and the parts of it that are weaker than the marketing version would be.

The retention, in full

Backups run through Proxmox Backup Server, deduplicated and incremental, and are kept to this schedule:

• 24 hourly
• 7 daily
• 4 weekly
• 12 monthly
• 1 yearly

That set is kept on-site and as an encrypted off-site copy. The same wording appears in the terms of service, deliberately word for word, so there is no gap between what the marketing page says and what you can hold anyone to.

What the schedule buys you is granularity where you need it and depth where you might. A griefing incident or a bad plugin update is usually discovered within hours, so the hourly copies matter most. A world corruption that nobody noticed for three weeks is rarer, and that is what the weekly and monthly copies are for.

Why incremental and deduplicated matters to you

Proxmox Backup Server splits data into chunks and stores each unique chunk once. A Minecraft world where twenty chunks changed since the last run costs roughly twenty chunks of storage, not another copy of the world.

The reason that is your problem and not just mine: it is what makes 48 restore points per server economically possible at all. A host taking full copies would either keep far fewer of them or charge you for the storage. Deduplication is the difference between "we keep a backup" and "we keep 44 of them".

Backups are encrypted with AES-256-GCM before they leave, and transferred over TLS. The off-site copy is encrypted at rest, which is the only sane way to put customer worlds on hardware you do not own.

Verification checks integrity, not restorability

This is the part most hosts blur, so it is worth being exact.

Proxmox Backup Server verifies backups using SHA-256 checksums. That proves the stored chunks are intact and have not rotted. It is a genuinely valuable thing to run and it catches silent corruption.

What it does not prove is that the backup restores into a working server. A checksum-valid copy of a world that was already corrupt when it was taken will verify perfectly and restore perfectly into the same corrupt world. Integrity and usefulness are different properties, and anyone telling you their verified backups are guaranteed restorable is describing a stronger guarantee than the tooling gives.

The honest position: the copies are provably intact, and a restore is a thing I have done, but "verified" in the panel means checksums passed.

raidz2 is not a backup, and the rebuild is the risky part

The storage is seven Samsung SATA SSDs in ZFS raidz2, 2.38TB usable, which tolerates two simultaneous drive failures. That is real protection and it is why a dead drive is not an incident.

It is not a backup, for the obvious reason that RAID replicates whatever you do. Delete your world and raidz2 replicates the deletion across every disk instantly and reliably. It protects against hardware failure, and hardware failure is not the thing most likely to lose your world. You are.

There is also a subtler risk worth naming. When a drive fails and is replaced, the array resilvers, and during the rebuild every remaining disk is read heavily. That is precisely the moment a second marginal drive is most likely to give up. raidz2 tolerating two failures is not a comfortable margin during a rebuild, it is the margin that makes a rebuild survivable at all. SSDs resilver considerably faster than spinning disks, which shortens the window, and that is a large part of why the array is SSD.

What this will not save you from

• A mistake you do not notice for more than a year. Beyond the yearly copy, there is nothing. If you overwrite a build and discover it fourteen months later, it is gone.
• A backup of already-broken data. If a world was corrupt at the moment the snapshot ran, restoring it gives you the corruption back. Restore points are only as good as the state they captured.
• Your own account being compromised. Backups protect against data loss, not against someone who has your credentials and the ability to delete things through the panel. Use the two-factor authentication in the panel, and give staff sub-user accounts with only the permissions they need rather than sharing the main login.
• Anything on a VPS you have not configured yourself. The node's backups cover the platform. What runs inside a VPS you have root on is yours to protect.

What to actually do

Take your own copy of anything irreplaceable. Not because the backups here are untrustworthy, but because a backup held by your host protects you against your host's failures and not against your relationship with your host ending. Pull the world directory over SFTP occasionally. It is the only artefact that cannot be regenerated: server binaries, plugins and configs can all be fetched again.

Before any risky change, take a manual snapshot rather than relying on the scheduled one. The scheduled copy might be 55 minutes old. The one you took deliberately is zero minutes old and you know exactly what state it captured.