Pull server backups to your own PC: a Windows backup agent

A backup that lives with the same provider as the server it protects covers most accidents, but not all of them. The ones it misses are the ones where you lose access to the provider side: a deleted server, a lapsed payment, a compromised account. The fix is cheap: keep a second copy on a machine you control, usually the PC you are reading this on. You can do it by hand from the panel's Backups tab, or you can let a small scheduled script do it for you - list the server's finished backups, download any it does not have yet, check that each archive opens, and delete the oldest local copies. This post builds that script for Windows, schedules it with Task Scheduler, and covers the parts people get wrong: what an archive does and does not contain, where the API key lives, and how to tell a good copy from a corrupt one.

One note before we start, because the name invites it. We run a program of our own, also called the RENODE Backup Agent, to pull copies off the node every day for our platform. That one is internal and is not something you download. What follows is the same idea, built from parts any Windows machine already has, pointed at your own servers.

Why a copy on your own machine matters#

Backups on a hosting panel are already a good deal better than nothing. On RE:NODE they are stored off the machine they protect, so a dead disk on the node does not take the backups with it, and you can lock a backup so that rotation never removes it. That covers the common failures: a bad plugin update, a corrupted world, a config edit that will not boot.

What a provider-side backup cannot cover is the provider side itself. The plain cases:

• The server is deleted. Deleting a server on RE:NODE deletes its backups too, locked ones included. That is the right behaviour for privacy, and it means a mistaken delete, or a subuser with too much access, takes every copy at once.
• The service lapses. A card expires, the renewal email lands in spam, and a server you stopped watching runs past its grace period. Whatever happens to the files then, they are no longer yours to fetch.
• The account is compromised. Someone with your panel password and no 2FA can delete backups before they delete anything else. A copy on your PC is out of their reach.
• You want to leave. Moving to another host, or to a box at home, starts with having the data. A folder of archives on your own disk is the easiest migration you will ever do.

This is the old 3-2-1 rule with the numbers filled in: three copies (the live server, the panel backup, your PC), on two kinds of storage, one of them away from the other two. Your PC is the "away" copy. It is not a perfect one - home disks fail, laptops get stolen - but it fails for completely different reasons than the hosting side does, and that is the whole point. For the wider strategy, game server backup strategy goes through slots, frequency and what to lock.

What RE:NODE already does, and what it leaves to you#

It helps to know which copies exist before adding another, so you know what the new one is for.

• Your backups. Every plan has backup slots - two on most game plans, a range on app, web and database plans. You make them on demand or from a schedule, restore them with a button, download them, and lock the ones you want to keep. They live off the machine they protect. These are the ones this post pulls.
• Nightly system backups. Every server is also backed up every night, whatever its plan's slot count, outside your quota. Those are ours: they do not show on your Backups tab and you cannot download them. If you need one restored, that goes through support. Nightly backups outside your quota explains how they work.
• Platform backups. Separately, the platform itself is backed up nightly to separate hardware, verified and pruned, and we pull copies off the node every day.

None of those three is a copy you hold. The nightly system backup is a safety net we keep for incidents; it is not a substitute for your own, and it is not something you can reach at three in the morning when you need it. The copy on your PC is the one that depends on nobody but you.

What a backup archive contains#

Before automating anything, be clear about what you are pulling, because the most common surprise in a restore is something that was never in the archive.

A server backup is a .tar.gz of the server's files. A database you created in the panel's Databases tab lives on a database server, not in the server's file system, so it is not in the archive. If your Minecraft plugins, your FiveM resources or your Discord bot keep data in that database, a file backup alone restores a server that cannot find its data. Dump the database on its own - mysqldump backup and restore has the commands - and have the dump land in the server's files before the backup runs, so it rides along in the archive.

The other gap is .pteroignore. It is a file in the server's root that works like .gitignore: anything it lists is skipped when a backup is made. It is useful for leaving out logs and caches, and dangerous when someone added world/ to it months ago to save space. Open it before you trust any archive.

Startup variables - the version, the jar, the environment values on the Startup tab - are not files either. Write them down once. Rebuilding them from memory during an outage is slow.

The manual way: download from the Backups tab#

If you only want a copy now and then, there is nothing to install.

1. Open the server in the panel and go to the Backups tab.
2. If the newest backup is old, press the button to create one and wait until it shows as finished.
3. Open the menu on that backup and choose Download. The browser fetches a .tar.gz through a short-lived signed link.
4. Move the file somewhere that is not your Downloads folder, and rename it with the date and server name.

That is fine before a risky change or before cancelling. It is not a backup routine, because it depends on you remembering, and the backups you most need are the ones from the week you forgot. The rest of this post makes it automatic. The panel side of backups is also covered in the backups guide.

Automating it with PowerShell and the client API#

RE:NODE's panel is built on Pterodactyl, and its client API is what the panel's own pages use to list and download backups. With a client API key you can make the same two calls from a script. We do not publish an API reference of our own, so treat what follows as the upstream Pterodactyl client API and test it against your own server before relying on it.

You need three things:

• An API key. Create one in the panel under your account's API credentials. It starts with ptlc_. You can restrict a key to particular addresses; if your home connection has a fixed IP, do that. If the IP changes, a restricted key will start failing, which is safer than an open one but worth knowing about.
• The server's short ID. It is the eight-character part of the server's URL in the panel, for example a1b2c3d4 in /server/a1b2c3d4.
• A folder with room. Count the archive size times the number of copies you want to keep, plus a margin.

Store the key as a user environment variable, not in the script, so the script can be shared or committed without leaking it:

setx RENODE_API_KEY "ptlc_your_key_here"

setx writes the variable for future sessions, so open a new PowerShell window afterwards. The scheduled task we create later runs as your user and sees it.

Now the script. Save it as C:\ServerBackups\pull.ps1:

$Panel  = 'https://panel.renode.space'$Server = 'a1b2c3d4'$Dest   = "C:\ServerBackups\$Server"$Keep   = 14$Key    = $env:RENODE_API_KEY[Net.ServicePointManager]::SecurityProtocol = 'Tls12'$ProgressPreference = 'SilentlyContinue'$Headers = @{ Authorization = "Bearer $Key"; Accept = 'application/json' }$Base = "$Panel/api/client/servers/$Server/backups"New-Item -ItemType Directory -Force -Path $Dest | Out-Null$Log = Join-Path $Dest 'pull.log'$list = Invoke-RestMethod -Headers $Headers -Uri $Baseforeach ($b in $list.data) {  $a = $b.attributes  if (-not $a.is_successful -or -not $a.completed_at) { continue }  $stamp = ([datetime]$a.completed_at).ToString('yyyy-MM-dd_HHmm')  $file  = Join-Path $Dest ("$stamp-" + $a.uuid.Substring(0,8) + '.tar.gz')  if (Test-Path $file) { continue }  $link = Invoke-RestMethod -Headers $Headers -Uri "$Base/$($a.uuid)/download"  Invoke-WebRequest -Uri $link.attributes.url -OutFile "$file.part" -UseBasicParsing  tar -tzf "$file.part" > $null 2>&1  if ($LASTEXITCODE -ne 0) {    Add-Content $Log "$(Get-Date -f s) BAD archive $stamp, kept as .part"    continue  }  Move-Item "$file.part" $file  Add-Content $Log "$(Get-Date -f s) pulled $stamp $($a.name)"}Get-ChildItem $Dest -Filter *.tar.gz |  Sort-Object LastWriteTime -Descending |  Select-Object -Skip $Keep |  Remove-Item

It is written for Windows PowerShell 5.1, the version every Windows 10 and 11 machine already has, so there is nothing to install. The fence is marked as plain text only because of how the blog colours code; the file itself is an ordinary .ps1.

What each part does

The first block is configuration. $Keep is how many archives to hold on the PC; fourteen with a daily panel backup is two weeks. The SecurityProtocol line forces TLS 1.2, which older 5.1 installs do not always pick by default. $ProgressPreference matters more than it looks: in Windows PowerShell 5.1, Invoke-WebRequest redraws a progress bar for every chunk, and on a multi-gigabyte archive that alone can make the download several times slower.

The loop asks the panel for the server's backups and skips any that failed or are still running. Each finished backup gets a file name built from its completion time and the first eight characters of its UUID, so the names sort by date and never collide. If the file already exists, the script moves on - that is what makes it safe to run as often as you like. It only ever downloads what it does not have.

For a new backup it asks for a download link, which comes back as a signed URL that expires shortly, and downloads to a .part file. Only after tar -tzf has read the whole archive without an error is it renamed to .tar.gz. That one step is the difference between a backup folder and a folder of files that look like backups. tar ships with Windows 10 and 11, so this also needs nothing extra.

The last pipeline is retention: sort the archives newest first, skip the ones you want to keep, delete the rest. It only touches .tar.gz files in that server's folder, so a broken .part stays put for you to look at, and nothing else on your disk is in scope.

More than one server

Make $Server a list and wrap the body in a second loop, or keep one copy of the script per server with its own folder. Separate folders are easier to reason about when you restore, and one server with a broken key does not stop the others.

Scheduling the pull with Task Scheduler#

A script you have to remember to run is the manual way with extra steps. Windows Task Scheduler runs it for you. Open PowerShell as your normal user and register a task:

$action = New-ScheduledTaskAction -Execute 'powershell.exe' `  -Argument '-NoProfile -ExecutionPolicy Bypass -File C:\ServerBackups\pull.ps1'$daily  = New-ScheduledTaskTrigger -Daily -At 9am$logon  = New-ScheduledTaskTrigger -AtLogOn -User $env:USERNAME$opts   = New-ScheduledTaskSettingsSet -StartWhenAvailable `  -ExecutionTimeLimit (New-TimeSpan -Hours 3)Register-ScheduledTask -TaskName 'Server backup pull' `  -Action $action -Trigger $daily,$logon -Settings $opts

Two triggers on purpose. A home PC is often off at whatever time you pick, so a daily trigger alone misses days. The logon trigger runs it whenever you sign in, and -StartWhenAvailable tells Windows to run a missed daily start as soon as the machine is back. Because the script only downloads what it lacks, running it twice in a morning costs one API call.

-ExecutionTimeLimit stops a hung download from sitting there forever; three hours is generous for most archives. If you have servers measured in tens of gigabytes on a slow line, raise it.

Line it up with the panel's backup schedule

The pull can only fetch what exists. On the panel side, open the server's Schedules tab and add a schedule with a backup task, using a cron expression for the time you want. If the panel backup runs at 05:00 and your PC pulls at 09:00 and at logon, every morning's copy reaches your disk the same day. Cron expressions explained covers the five fields if you have not written one before, and scheduled tasks worth having suggests what else belongs on that tab.

Mind the slot count. A game plan with two backup slots rotates: when both are full, a scheduled backup replaces the oldest unlocked one. That is fine here - your PC keeps the history the panel has no room for. It is also the best argument for the pull: two slots on the server, fourteen days on your disk.

Checking that the copies are any good#

A file with the right name and size is not yet a backup. "A backup nobody has restored is a hypothesis," and the same goes for a downloaded one. The script already lists every archive end to end, which catches truncated downloads and corrupt gzip streams. That is the first layer.

The second layer is looking inside. Once a month, take the newest archive and list what is in it:

tar -tzf C:\ServerBackups\a1b2c3d4\2026-10-16_0500-3f9a1c2e.tar.gz | more

You are checking that the world folder, the config files and the plugin data are there and are not suspiciously small. If the world is missing, look at .pteroignore before you look anywhere else.

The third layer is an actual restore, and it is the only one that proves anything. Unpack the archive into an empty folder and start the server from it - on your PC if the game runs there, or on a spare server. Testing a restore before you need it walks through doing this without touching production, and backups that actually restore covers the failure modes that only show up at this step.

Keeping the local copy safe#

The copy on your PC is only "away" if it stays separate from the things that can hurt the server.

• Do not sync it straight back to the cloud. A backup folder inside OneDrive or Dropbox is fine as a third copy, but sync clients mirror deletions. If ransomware or a bad script empties the folder, the empty folder syncs. Use version history, or keep the sync copy separate from the pull folder.
• Keep a weekly offline copy. An external disk that you plug in, copy to and unplug is the one copy ransomware on your PC cannot reach. robocopy C:\ServerBackups E:\ServerBackups /E does it in one line.
• Protect the key. The API key can do anything your account can do on the servers it can reach. Restrict it by address if you can, keep it in the environment variable rather than the script, and revoke it in the panel if the PC is lost.
• Mind the disk. Game archives grow with the world. Look at the folder size after the first fortnight and adjust $Keep before the disk fills, rather than after.

If you would rather the copy lived somewhere other than your PC, the same pattern works with object storage: game server backups to S3 and rclone with S3 storage cover that route.

Troubleshooting the pull#

The script writes one line per archive to pull.log in the server's backup folder, and Task Scheduler keeps the last run result for the task. Between them, most failures are easy to place.

• 401 or 403 from the API. The key is wrong, revoked, or restricted to an address you are not on. Check the key in a fresh window with echo $env:RENODE_API_KEY; if it is empty, setx ran but this session started before it. If you restricted the key by IP and your connection's address changed, add the new one.
• 404 on the server. The short ID is wrong, or the key belongs to an account that is not the owner or a subuser of that server.
• The task shows success but nothing downloads. There may be nothing new. Check the Backups tab: if the last backup failed or is still running, the script skips it by design.
• Downloads are painfully slow. Make sure the $ProgressPreference line is there. Without it, Windows PowerShell 5.1 spends much of its time drawing the progress bar.
• A `.part` file stays behind with a BAD line in the log. The download was cut off or the archive is damaged. Delete the .part file; the next run fetches it again. If the same backup fails every time, make a fresh one in the panel and check whether that one passes.
• "Running scripts is disabled on this system". That is the execution policy. The task passes -ExecutionPolicy Bypass for this one script; when running it by hand, use the same flag rather than loosening the policy for the whole machine.
• The task never runs when you are logged out. Tasks registered this way run only while you are signed in, which is what lets them read your user environment variable. If you need it to run with nobody signed in, register it with a stored password and move the key into a file only that account can read.

FAQ#

Can I download the nightly backups RE:NODE makes?

No. The nightly system backups are ours, kept for incidents, and they are hidden from the Backups tab. A restore from one goes through support. The backups you can download, and that this script pulls, are the ones in your own slots.

Is there an official RE:NODE backup app to install?

No. We do run an internal program to pull copies off the node every day for the platform, but it is not a customer download. The script in this post does the same job for your own servers with tools already on Windows.

Does the downloaded archive include my database?

No. A server backup archive is the server's files. A database slot is a separate thing and needs its own dump. Write the dump into the server's files before the backup runs and it will be inside the archive you pull.

How many copies should I keep on my PC?

Enough to go back past the point where a problem was noticed. Griefing, a corrupt chunk or a bad plugin are often spotted days later, so a week is the minimum and two weeks is comfortable. Disk space is usually the only limit.

Will pulling backups slow down my server?

No. The download reads an archive that already exists in backup storage; the game server is not involved. Making the backup in the first place takes some disk and CPU on the node, so schedule that for a quiet hour.

Can I use this on a Mac or Linux machine?

The idea carries over directly - two API calls, a download, tar -tzf, a retention step - but the script is PowerShell and the scheduler is Windows. On Linux or macOS the equivalent is a short shell script with curl and a cron entry.