How to Set Up Automated Backups for Your Pterodactyl Server
The backup button exists. You just never click it.
Pterodactyl has a backup system built right into the panel. It is sitting there in your server console, waiting patiently for you to remember it exists. Most people do not remember until something goes wrong.
The built-in system works like this: you click the button (or hit the API endpoint), Wings compresses your server files into a tar.gz archive, and stores it either locally on the Wings node or in an S3 bucket if the panel admin configured one. Simple enough.
The problem is that "click a button when you remember" is not really an automated backup strategy.
What Pterodactyl actually gives you
The built-in backup feature is decent for what it is. Here is the honest breakdown:
- Manual triggers only. There is no built-in scheduler. You click the button, or you write something that hits the API on a timer. The panel itself will never create a backup on its own.
- Host-controlled limits. Your hosting provider decides how many backups you can keep. Many set this to 2 or 3. Some set it to 0, which disables the feature entirely. You do not get a say.
- All-or-nothing. It backs up everything in your server directory. Every log file, every temporary cache, every 3GB asset pack you will never need to restore. There is no way to say "just back up my save files and configs."
- Restores replace everything. When you restore a backup, it overwrites the entire server directory. Want to just grab one config file? Too bad. It is the whole thing or nothing.
For a small server you check on once a week, this might be fine. For anything you actually care about, it is a bit thin.
The S3 route (if you have panel access)
Pterodactyl supports S3-compatible storage for backups. If you are the panel administrator, you can add these to your Wings .env file:
AWS_ACCESS_KEY_ID=your-key
AWS_SECRET_ACCESS_KEY=your-secret
AWS_BACKUPS_BUCKET=your-bucket-name
AWS_ENDPOINT=https://s3.amazonaws.com
This sends your backups to cloud storage instead of saving them on the local disk. Good idea. One problem: most people running game servers are not the panel admin. They are clients on a shared hosting provider. They do not have access to the Wings .env file, and their host is not going to hand it over.
Even if you are the admin, the backups still count against the per-server limit. You still have no scheduling. You still cannot pick which files to include.
Writing your own cron job
The next step for most people is writing a script that calls the Pterodactyl API on a timer. Something like:
curl -X POST "https://panel.example.com/api/client/servers/abc123/backups" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json"
Throw that in a cron job, and you have automated backups. Sort of. You still need to deal with:
- Backup rotation. Old backups pile up until you hit the limit. Then new ones fail silently.
- Error handling. If the API call fails, you will not know unless you added logging.
- Monitoring. Is it still running? Did the server restart and lose the cron entry? Who knows.
- The backup limit. You still cannot exceed what the host allows.
There are a few community scripts on GitHub that try to solve this. pterodactyl-automated-backups is a Python script with about 30 stars that iterates through your servers and triggers backups. It works, but it is still bound by the same panel limitations. You are automating the button click, not fixing the underlying constraints.
When your host disables backups entirely
Here is the fun part: some hosting providers disable the backup API endpoint completely. They either set the backup limit to 0 or block the endpoint at the network level. In that case, none of the above matters. You cannot back up through Pterodactyl at all.
This is more common than you would expect. Backups use disk space and CPU time on the Wings node, and hosts would rather you did not use either.
What we built instead
Pink Narwhal does not use the Pterodactyl backup API at all. It works through the file manager API, which is a different endpoint that hosts essentially never disable (because the entire panel would be useless without it).
Here is what that means in practice:
- No backup limit. Since it does not use the backup system, host-imposed limits do not apply.
- Scheduled automatically. You pick a time, it runs. Every day, every hour, whatever your plan supports.
- Game-aware profiles. Instead of backing up everything, it knows which files matter for your specific game. Rust save files, Minecraft worlds, Discord bot configs. The junk gets skipped.
- Stored in Cloudflare R2. Your backups live in their own cloud storage bucket, not on the Wings node. The node can catch fire and your backups are fine.
- Selective restore. You can browse a backup and download individual files. No more restoring the entire server to get one config back.
The honest summary
If your host gives you a reasonable backup limit, the built-in system plus a cron job works fine for basic coverage. If your host is stingy about limits (or disables backups outright), or if you want actual scheduling, game-aware file selection, and offsite storage, that is where Pink Narwhal fits in.
You do not need to pick one or the other. The built-in system and Pink Narwhal use completely different APIs and do not interfere with each other. Belt and suspenders.