Nightly server backups outside your quota: what they cover

Every server on RE:NODE is backed up every night, whatever its plan, and those backups do not use any of your backup slots. Plans with no backup slots at all get them too. The databases a game server keeps in the panel are dumped separately each night, because a server archive holds files only. These nightly copies are system backups: you do not see them on the Backups tab and you cannot restore them yourself - you ask support, and we restore from them. They are a safety net under everything else, and a short-lived one. Your own backups, made in your own slots on your own schedule, are still the ones you control, and a copy that lives off our platform entirely is still the one that survives the things a host cannot protect you from. This post covers all three layers: what the nightly run does, how each kind of restore works, and how to keep an off-site copy without much effort.

The short version, if you only read one paragraph: the nightly backup is there for the day something goes wrong that you did not see coming. It is not a history, it is not a versioning system, and it is not a reason to stop taking your own backups before an update or a wipe.

What the nightly backup covers#

The nightly run walks through every server on a node once a day and makes a full archive of each one. "Every server" means what it says: game servers, app servers, web servers, database servers. It does not matter what the plan's backup limit is - a plan that allows zero backups still gets one each night, and a plan with six slots full of your own backups still gets one each night, because the system backup is counted outside the limit.

A few things are true of the system backups that are worth knowing before you need one:

• They are hidden. They do not appear on your Backups tab, and the panel will not let a customer list, download, delete or restore them. That is deliberate: it means nobody with access to your account, including a subuser who should not have that power, can remove the safety net.
• They hold files. An archive is a copy of the server's file system - worlds, configs, plugins, uploads, code. It does not include databases you created in the panel's Databases tab; those live in a separate database service and are dumped on their own.
• They are recent, not historical. We keep a short rolling window of the latest nights, not weeks of history. If a problem started a fortnight ago and you only noticed today, the nightly backups will not reach back far enough. Your own backups, locked against rotation, are how you keep an older known-good point.
• They pause rather than fill a disk. If a node is running short of free space, the nightly run waits instead of starting new archives, because a full disk would take every server on that node down with it. Backups resume once space is back.

The "outside your quota" part is the main practical difference from most panels. On a stock Pterodactyl setup a backup is a backup: if the host makes one for you, it sits in the same list and counts against the same limit. Here your slots are yours. You can fill them with your own copies before an update, lock the ones that matter, and the nightly safety net carries on underneath without competing for space.

The database dumps#

A game server that uses a database - a Minecraft server with LuckPerms or an economy plugin on MySQL, a FiveM server on oxmysql, a Garry's Mod DarkRP server storing player data - keeps that database outside its own file system. On RE:NODE game plans come with one database slot, created in the panel with a generated host, user and password. The data in it is not inside the server's archive, so restoring a file backup alone gives you the world and the configs as they were, with the database as it is now.

That is why the databases are dumped separately every night. A dump is a SQL file: the CREATE TABLE statements and the rows, written out in a form that can be replayed into an empty database. Unlike a copy of the database's own data files, a dump taken by the database server itself is consistent - it does not catch a table halfway through a write.

The consequence for restores is simple and easy to forget: if you roll a server back, roll its database back to the same night, or you get a world from Tuesday with a player inventory from Friday. With plugins that store ranks, balances or claims in MySQL, a mismatch like that is usually worse than either version on its own. When you ask us to restore from a nightly backup, say whether you want the database restored to the same night.

The same reasoning applies to your own backups, which hold files only. If you take a backup before a big plugin update, take a database export at the same moment - phpMyAdmin's export or a mysqldump from your own machine - and keep the two together. The mysqldump guide has the flags that matter.

$ mysqldump --single-transaction --routines --triggers \    -h HOST -P PORT -u USER -p DATABASE | gzip > db-$(date +%F).sql.gz

Use the host, port, user and database name shown on the server's Databases tab. --single-transaction gives a consistent snapshot of InnoDB tables without locking them, which is what you want on a live game server.

How the layers fit together#

There are three places a copy of your server can be: on our side as a system backup, on our side as a backup you made, and somewhere that is not us at all. They protect against different things.

The last two rows are the uncomfortable ones. Deleting a server deletes its backups, including the ones you locked. If you cancel a server or lose access to your account, everything stored on our side goes with it. A copy you hold yourself does not.

Restoring from a nightly backup#

Because system backups are hidden from the panel, a restore from one goes through support. You can reach us with a ticket from the panel or through the Chat button in the server header, which opens a conversation with staff beside the console and still works when a server is suspended or an install has failed. Discord and email work as well.

To get the restore done quickly and correctly, say:

1. Which server. The server name, or better, its identifier from the address bar.
2. Which night. "The backup from before Thursday's update" is more useful than "the latest one", because the latest one may already contain the problem.
3. What to restore. The whole server, or particular folders - only the world, only the plugin configs.
4. The database too or not. Usually yes, to the same night, for the reasons above.
5. Whether to keep the current state. If you might want something from the broken version, take a backup of it in your own slot first, or download the files you care about. A full restore replaces what is there.

Stop the server before the restore if you can. A running game server can write its world back to disk on shutdown, overwriting a restored save with the state it had in memory. For most games that is the difference between a restore that worked and one that silently did not.

Restoring from your own backups#

For the backups in your own slots there is no one to ask. The Backups tab lists them; each can be restored with a button, downloaded as an archive, or locked so that rotation does not remove it. The panel guide walks through the screens.

The difference between a full restore and a partial one matters here, because most real problems do not need the whole server put back.

• Full restore. Stop the server, restore from the Backups tab, start it. Use this after a broken update or a mod that corrupted things you cannot list.
• One world or one folder. Download the backup, unpack it on your own machine, and upload only the folder you need through the file manager or SFTP. The rest of the server stays as it is.
• One file. The same, for a single config. This is the usual fix for "someone edited server.properties and now nothing works".

$ mkdir restore && tar -xzf backup.tar.gz -C restore$ ls restore

Then upload the folder you want with any SFTP client, using the credentials on the server's SFTP details. The SFTP and file manager guide covers clients and the usual permission errors.

Lock at least one backup you know is good. Rotation is helpful right up to the moment it removes the last copy from before a problem you had not spotted yet. A locked backup taken after a clean start, before each big change, costs one slot and saves the argument about whether the rollback point still exists.

Scheduling your own backups#

The nightly system backup runs whether you do anything or not. Your own backups run when you tell them to, and the Schedules tab is how you make that automatic. A schedule takes a cron expression and an ordered list of tasks with delays between them: console commands, a backup, a power action.

A sensible pattern for a game server is to warn players, save the world from the console, back up, and only then restart if you restart at all:

The save command depends on the game - save-all on Minecraft, save on many others; check your game's console reference. The point of saving first is that the backup archives what is on disk, and a game that holds the world in memory between autosaves will otherwise give you a copy that is minutes old. Cron expressions explained covers the timing syntax and scheduled tasks worth having has more patterns.

How often depends on how much play you can afford to lose. A small server for friends is well served by one scheduled backup a day plus a manual one before every update. A busy community server may want several a day. With a limited number of slots, rotation keeps the newest and drops the oldest, which is why locking one known-good copy matters.

Why you still keep an off-site copy#

Nightly backups protect you from the failures that happen to servers: a bad update, a corrupted save, a plugin that wipes a table. We pull copies of them off the node every day, so they are not on the same machine they protect. What they cannot protect you from is anything that happens to the relationship between you and us.

• Deleting the server deletes its backups. Ours and yours, locked ones included. A mistaken delete is not recoverable from our side.
• A cancelled service goes the same way. When a server is removed, for whatever reason, its backups are removed with it.
• Your account is a single point of failure. If you lose both your two-factor device and your recovery codes, the account cannot be recovered, and neither can anything only reachable through it.
• Any host is one supplier. This is not specific to us. A copy that only exists inside one company's systems depends on that company in every way, and the 3-2-1 rule - three copies, two kinds of storage, one somewhere else - exists because people learned that the hard way.

A backup that only exists inside the service it is backing up is a feature of that service, not a backup.

The off-site copy does not need to be frequent. Weekly is fine for most game servers, plus one before any major change. What matters is that it exists, is somewhere you control, and has been opened at least once to check it restores.

Making the off-site copy#

There are three practical ways, from least effort to most automated.

The first is manual: download a backup from the Backups tab every week or before a big change and keep it on your own disk or cloud drive. It takes a minute, which is also why people stop doing it after a month.

The second is a sync from your own machine over SFTP with rclone. Configure an SFTP remote with the host, port, username and password from the panel's SFTP details, then copy the folders that matter:

$ rclone config create renode sftp host HOST port PORT user USER pass PASSWORD$ rclone copy renode:world ./server-backup/$(date +%F)/world --progress

Copy only what you need - world, configs, plugin data - not the game binaries, which reinstall anyway. Pair it with a database dump from the same moment. Note that rclone config create obscures the password before storing it, but the config file still lets anyone who reads it log in, so keep it on a machine you trust.

The third is object storage: send your copies to an S3-compatible bucket with rclone or restic. Restic adds deduplication, encryption and its own retention rules, which suits a copy that runs on a timer from a machine you own. Game server backups to S3 and restic backups to S3 cover both in full. RE:NODE sells S3 object storage too, but be clear about what that is: it is on the same platform, in the same location, as your server. It is a good second kind of storage and a convenient target for scripts; it is not the "somewhere else" in 3-2-1. For that, the bucket or the disk has to belong to someone other than your host.

Whichever you choose, restore from it once. Unpack the archive, load the dump into a scratch database, start a copy of the server from it if you can. Testing a restore before you need it has the checklist, and backups that actually restore explains why the test is the backup's real job. A backup nobody has restored is a hypothesis.

What nightly backups do not replace#

To be plain about the limits, so nobody plans around something that is not there:

• No self-service restore of system backups. It goes through support, so it takes as long as a conversation with staff, not one click. For anything you may need back in a hurry, your own backup is faster.
• No long history. The window is short. Older recovery points are yours to keep, locked in your slots or off-site.
• No point-in-time recovery. A nightly backup is a nightly backup. Anything between last night and now exists only on the live server.
• No protection from deletion. Delete a server and its backups go with it.
• No database-engine backups for database hosting plans beyond the file archive. Database servers get the nightly file archive like everything else, but a file copy of a running database engine is not the same as a dump taken by the engine. For PostgreSQL, MongoDB, MySQL or SQL Server plans, schedule your own dumps - database backups and restores and database dumps to S3 on a schedule show how.

None of that makes the nightly backup less useful. Most of the bad days a server owner has are the kind it covers: an update that went wrong last night, a config edited badly this morning, a mod that corrupted a save. It just is not the whole plan, and treating it as the whole plan is how people end up asking for a copy from three weeks ago that does not exist.

FAQ#

Do nightly backups count against my plan's backup slots?

No. They are system backups, made outside your plan's backup limit, so every slot on your plan stays free for your own copies. Plans with no backup slots get the nightly backup as well.

Can I download or restore a nightly backup myself?

No. They are hidden from the Backups tab so that nobody with panel access can delete them. To restore from one, open a ticket or use the server chat and say which night and which parts you want back.

Are plugin and mod databases included?

Databases created in the panel for a game server are dumped separately every night, since the server archive holds files only. Ask for the database to be restored to the same night as the files, or the two will not match.

How far back do the nightly backups go?

Only a short rolling window of recent nights. They are for recovering from something that went wrong recently. For an older known-good point, lock one of your own backups or keep a copy off-site.

If I delete my server, can support bring it back?

No. Deleting a server deletes its backups, locked ones included, and the system backups are no exception. The only copy that survives a deletion is one you downloaded or synced somewhere yourself.

Do I need my own backups if nightly ones exist?

Yes. Take one before every update, wipe or big config change, so you can roll back yourself in one click without waiting for anyone, and keep one locked as a known-good point the nightly window cannot reach.