Search the Community

A manual DayZ backup is a copy of your mission folder pulled down over SFTP with the instance stopped: open the SFTP tab for the credentials, connect on port 2022, then download mpmissions/<world>/ including the whole storage_* folder and all three of players.db, players.db-wal and players.db-shm. That is the entire persistence set, and once it is on your own disk it is yours indefinitely. The Backups tab cannot do this for you. It has no create-now button and no download button, and its history is only 30 days, so an off-site archive, a snapshot taken minutes before a risky change, or a copy to load onto a test server is a job you do by hand. This guide covers doing it correctly — and the one mistake that turns the whole exercise into a corrupt file. On this page Stop the instance before you copy anythingConnect over SFTP and find your world folderDownload the whole world folderTake serverDZ.cfg and a record of your mod list tooVerify the copy before you start the server againDecide how many copies you keep, and for how longPut your own copy back when you need itTroubleshootingFrequently asked questions Before you start Your SFTP details: the Host, Port (2022) and Username from the SFTP tab, plus your SFTP password. Connecting with SFTP covers getting them and setting up a client.The Start / stop / restart permission as well as Read files. A copy taken while the server is running is not a backup, so you need to be able to stop it.A maintenance window. The instance stays down for the length of the copy — usually a few minutes, longer on a mature world.Free disk space locally, and somewhere sensible to keep the copy. A mature storage_1 folder is commonly a few hundred megabytes. The persistence set on a stopped DayZ server: players.db with its -wal and -shm siblings, plus the world data beside them. 1. Stop the instance before you copy anything This is the whole guide in one instruction. Do it first, and everything else is straightforward. Data loss risk: players.db is an SQLite database running in write-ahead log mode. Copy it while the server is running and you get a torn, stale or outright unreadable file — and copy players.db without its -wal sibling and you silently lose every write that had not yet been folded into the main file. Either mistake produces a backup that looks fine in your file manager and destroys your world the day you restore it. Stop the instance, wait for Server Status to read Stopped, and only then start the transfer. Click Stop on Overview. If players are online, run a Controlled Restart first so they are warned and can log out somewhere safe, then stop the instance once it is back up — restarting without rollbacks explains what an abrupt kill costs them. Wait for the status pill. DayZ flushes persistence as it shuts down, so a copy started while the process is still exiting can catch the world mid-write. Stopped means the handles are closed and the files on disk are the truth. Note: The panel’s own scheduled backups genuinely do not need downtime, and that is not a contradiction: the node takes a Volume Shadow Copy snapshot of the disk before it reads anything, so it gets a consistent point-in-time image while DayZ holds the database open. Your SFTP client has no equivalent trick — it reads live files one at a time. Wait for Server Status: Stopped before you begin the transfer — a hot copy of players.db is worthless. 2. Connect over SFTP and find your world folder Go to Instances → your instance → SFTP and take the Host, Port and Username from the Connection card — each has its own Copy button. The username is your panel username, a dot, and eight hexadecimal characters identifying this instance, so copy it verbatim rather than retyping it. Your session lands in a root holding exactly four folders: profiles, mpmissions, config and mods. Open mpmissions. Inside is one folder per mission world. The one you want is the value shown as Mission on Overview — dayzOffline.chernarusplus on a default Chernarus instance. If you have ever switched maps you will see more than one, and only the current mission is live; the others are old worlds sitting dormant. Open your world folder and you will find the mission configuration alongside a storage_* folder, normally storage_1. That storage folder is your persistence. Note: Nothing else on the server matters for a persistence backup, and the game binaries and BattlEye working directory are outside the four shares anyway — they cannot be reached over SFTP at all. 3. Download the whole world folder You can cherry-pick, but the reliable move is to drag the entire world folder to your local machine in one transfer. That captures all three of the things a restore might need, in the same layout the server expects them back in: What you are copyingWhat it holdsMatches the restore categorystorage_*/players.db plus -wal and -shmEvery character: inventory, position, health, stats.Players DBEverything else inside storage_*Built structures, vehicles, tents, buried stashes and other persisted world state.World DataThe world folder outside storage_*Your economy and mission config — the db folder, cfgeconomycore.xml, cfgspawnabletypes.xml and the rest.XMLs & JSONs & other(s) Laid out on disk it looks like this: mpmissions/ dayzOffline.chernarusplus/ download this whole folder db/ types.xml, events.xml, globals.xml cfgeconomycore.xml cfgspawnabletypes.xml storage_1/ players.db characters and inventory players.db-wal writes not yet folded into players.db players.db-shm data/ bases, vehicles, tents, stashes Drop it into a local folder named for the instance and the moment you took it — myserver-chernarus-2026-07-30-0300 — and leave the structure exactly as it came down. Do not rename anything, and do not delete the -shm file because it looks like scratch data. A copy that mirrors the server is one you can put back with a plain overwrite. Note: There is no size limit on SFTP downloads. The 2.5 GB ceiling applies to uploads only, so pulling a large world down is never the problem — pushing it back is where limits bite. Careful: Do not start the instance part-way through the transfer to “check it still works”. The moment DayZ boots it reopens the database and begins writing, and the second half of your copy no longer matches the first. Downloading the entire mission world folder in one transfer captures persistence and economy config together. 4. Take serverDZ.cfg and a record of your mod list too Persistence is the part you cannot recreate, but two more things are worth five seconds each while you are connected. serverDZ.cfg. It lives in the config share. The panel writes this file for you from the typed Instance Settings editor, so it is reproducible — but a copy is a plain-text record of every value you tuned, and it is the first thing another host or a local test server will want. Grab whitelist.txt, ban.txt and priority.txt alongside it if you use them. All of these are protected files: you can download and overwrite them, but not delete or rename them over SFTP. Your mod list. There is no export button, so make your own record. The Workshop Mods tab shows an Order column and each mod’s numeric Workshop ID — a screenshot of that table does the job, and the mods share gives you the same list as one @ModName folder per installed mod. Note: Record the mod set with the backup, not separately. Persistence written while a mod was installed contains that mod’s items, and restoring it onto a server that no longer runs the mod is how you get a world full of errors. Mods marked ESSENTIAL come from the node template and are always present, so you only need to note the ones you added. Careful: Do not plan on backing up and restoring mod payloads themselves. Mods are re-downloaded from the Steam Workshop when you add them by ID, and the upload filter rejects executable and script types outright (.exe, .dll, .bat, .cmd, .ps1, .sh, .msi, .scr, .com), so pushing a whole mod folder back does not end well. Re-add by ID and let the panel resolve dependencies — see installing Steam Workshop mods. A screenshot of the Workshop Mods table is your mod list of record — load order and Workshop IDs in one frame. 5. Verify the copy before you start the server again The instance is still stopped, which means this is the only moment you can re-take a bad copy for free. Spend a minute on it. Compare counts and sizes. Put the remote and local panes side by side on the same folder; the file count and total size should match. Most clients flag a transfer that finished with skipped files — treat any skip as a failed backup, not a warning.Confirm all three database files. players.db, players.db-wal and players.db-shm must be present locally if they are present on the server. After a clean shutdown the -wal may be zero bytes or absent, which is fine — what is not fine is it existing on the server and not in your copy.Check the storage folder is not empty. storage_1/data should hold real files. An empty storage folder means you copied a shell.Open one of the XMLs. db/types.xml in a text editor proves the text files came down intact rather than truncated.If you zip it, open the zip. Confirm the archive lists the storage_1 folder and the database files. An archive nobody has opened is not a backup. Careful: You find out a backup is bad on the one day you need it. Verifying now costs a minute; discovering it after a griefing incident costs your players their progress. Once you are satisfied, click Start on Overview and confirm Server Status reads Running and Server FPS reports a number before you tell anyone the server is back. A verified manual backup: the dated folder, the storage folder intact, and all three players.db files accounted for. 6. Decide how many copies you keep, and for how long The Backups tab is your short window — 30 days of node-side history, restored in place. Your own copies are the long window, and they only help if taking them is a habit. A rolling set. Three recent copies suits most communities. Take one, delete the oldest, keep moving.One before every risky change. An economy rewrite, a mod that writes to persistence, a map change, a version upgrade. Take it minutes before, not last night — the value is that it predates the change by as little as possible.One a month, kept. The copy that outlives the 30-day retention, and the one you will be glad of when something went wrong six weeks ago and nobody noticed.One before you leave. Moving hosts means taking a full copy while you still have SFTP access — see migrating a DayZ server to a new host. Store them in two places, one of which is not your gaming PC, and label each copy with the date, the world and the mod set. Sizes are modest — even a large world is usually a few hundred megabytes zipped — so a year of monthly archives fits on any cloud drive. Note: Automatic and manual backups are complements, not alternatives. Leave the Backups tab on a real frequency for the fast, frequent, category-level rollbacks it is good at — automatic backups and restore covers those — and keep your own copies for depth, portability and anything older than a month. 7. Put your own copy back when you need it Restoring your copy is the download in reverse, with the same rule at the front of it. Data loss risk: Stop the instance and wait for Stopped before you upload a single file. A running DayZ server holds players.db open and rewrites the storage folder as it goes and again on shutdown, so an upload under a live server is either refused on a locked file or flushed away the next time the server saves — and a partial write into an open database can corrupt every character on it. Stop the instance on Overview and wait for Server Status to read Stopped.Connect over SFTP and navigate to mpmissions/<world>/ — the same world folder you took the copy from.Upload your saved folder over the top, letting your client overwrite. Take players.db, players.db-wal and players.db-shm together, from the same copy, in the same transfer.Click Start and check the thing you restored actually looks right in game before you announce that you are back. Data loss risk: Never mix files from different copies. A players.db paired with the -wal from another snapshot describes a state that never existed, and SQLite will either refuse it or apply writes that do not belong to it. One copy, all three files, one transfer. Two limits shape the upload. SFTP takes single files up to 2.5 GB; the web File Browser stops at 300 MB, and a mature storage folder routinely exceeds that, so the browser uploader will reject exactly the files you most need to put back. And nothing on the server unpacks archives — there is no extract feature in the File Browser or over SFTP — so upload the unzipped folder tree, not the zip. Careful: An upload overwrites what it matches and leaves everything else alone, so files that exist live but not in your copy survive the restore. For a true replacement rather than a merge, delete the files inside storage_* first — that needs the Delete files permission and is irreversible, so only do it when you mean to discard the live world. Note: If the copy you want is one the panel took rather than one you took, you do not need SFTP at all — use Restore on the Backups tab, which lets you put back Players DB, World Data and XMLs & JSONs & other(s) independently. Automatic backups and restore walks through it. Restoring a manual backup: upload the unzipped folder over the top with the instance stopped, overwriting in place. Troubleshooting My downloaded players.db is a different size to the one on the server, or it will not open Why it happens. It was copied while the instance was running. SQLite in write-ahead log mode is being written to continuously, so a live read catches the file mid-transaction and produces something torn or stale. Your file manager has no way to tell you this — the file looks perfectly normal. How to fix it. Delete the bad copy so you never restore it by accident, stop the instance, wait for Stopped, and take it again. If you cannot stop the server right now, use the Backups tab instead: the node snapshots the disk first, so its automatic backups are consistent even with players online. I restored my own backup and players lost the last few hours of progress Why it happens. Almost always a missing players.db-wal. The write-ahead log holds committed changes that have not yet been folded into players.db, so a copy of the main file alone rolls back to whenever the last checkpoint happened. Copying while the server was running produces the same symptom. How to fix it. Restore again from a copy that includes all three files, taken after the instance reported Stopped. Going forward, download the whole storage_* folder rather than picking files out of it — then there is nothing to forget. The File Browser will not upload my storage folder back Why it happens. The web uploader caps a single file at 300 MB and oversized files are skipped and reported in the upload summary. A mature storage_1 folder frequently contains files past that, and there is no extract feature to work around it by uploading a zip. How to fix it. Use SFTP, which takes single files up to 2.5 GB. This is exactly the case SFTP exists for — see connecting with SFTP. Upload the unzipped folder tree; nothing on the server can unpack an archive for you. Downloading a file in the File Browser fails with File too large to read Why it happens. The web file manager reads a file into memory to serve it, and that path is capped at 50 MB — the error reads File too large to read (>52 MB). players.db on a busy server passes that within weeks, and the world data usually already has. How to fix it. Take it over SFTP, where downloads have no size cap at all. Use the File Browser for reading logs and editing XML, and SFTP for anything binary or bulky. The transfer finished but some files were skipped or refused Why it happens. Three limits look alike from the client. Downloads need Read files on your Members grant, uploads additionally need Write files, and the upload filter rejects .exe, .dll, .bat, .cmd, .ps1, .sh, .msi, .scr and .com outright. How to fix it. Read your client’s transfer log and find the first failure rather than the last, then check the extension and your permissions under Members. Never treat a partially completed transfer as a backup — delete it and start over. Frequently asked questions Do I really have to stop the server to copy players.db? Yes, if you want the copy to be usable. players.db is an SQLite database in write-ahead log mode that DayZ holds open and writes to continuously, so reading it live gives you a torn or stale file. The panel’s scheduled backups avoid the problem a different way — the node takes a Volume Shadow Copy snapshot of the disk before reading, which is why those need no downtime and a hand-made copy does. Which files exactly are the persistence? Everything under mpmissions/<world>/storage_*/. That is players.db with its players.db-wal and players.db-shm companions, which hold every character and inventory, plus the rest of the folder, which holds built structures, vehicles, tents and buried stashes. Your economy and mission config — db/types.xml and friends — sits one level up in the world folder and is worth taking in the same pass. Can I download one of the panel’s automatic backups instead? No. Automatic backups live on the node and are only ever restored in place, so the Backups tab has no download button and no create-now button. A copy on your own disk has to be taken over SFTP, which is also what removes the 30-day retention limit — a file you have already downloaded is yours for as long as you keep it. Can I zip the folder on the server before downloading it? No — there is no compress or extract feature in the File Browser or over SFTP, in either direction. Download the folder as it is and compress it locally afterwards if you want a single tidy archive. The same limitation is why a restore has to be an upload of the unzipped folder tree rather than a zip you unpack on the server. How often should I take a manual backup? Immediately before anything risky, and on a light routine otherwise — three rolling copies plus one a month kept as an archive covers most communities. The automatic Backups tab already handles frequent, recent rollbacks, so your manual copies exist to cover the two things it cannot: getting the data off the node, and keeping it longer than 30 days. Can I load my copy onto a local DayZ server to test something? Yes, and it is one of the better reasons to keep manual copies. A DayZ server you run yourself uses the same mpmissions/<world>/storage_* layout, so the folder drops straight in with the local server stopped. Match the mod set as closely as you can — persistence written with a mod installed expects that mod to still be present — and treat the result as a sandbox, not a mirror. Related guides Getting started with the control panelAutomatic backups and restoreconnecting with SFTP

Backups on your DZSERVERS.HOST server run automatically on a frequency you choose, are kept for 30 days, and restore one category at a time — so you can roll back a griefed base without resetting a single player’s character, or put back only your economy XMLs after a bad edit. Everything lives on the Backups tab of your instance: a Backup schedule card, a Backup history list, and a restore panel where you tick which parts of which world to put back. This guide covers that automatic side. There is no create-now button and no download button on the tab, which is deliberate: a copy on your own disk is a separate job over SFTP. On this page Open the Backups tabChoose a backup frequencyKnow what is in a backup, and what is notRead the backup historyStop the server before you restoreRestore only the parts you needWatch it finish, then start the serverKeep your own copy for anything older than 30 daysTroubleshootingFrequently asked questions Before you start An instance and the Manage backups permission. The Backups tab only appears in the tab bar if you have it.The Start / stop / restart permission too if you intend to restore — a restore needs the server stopped, and both the panel and the node refuse otherwise.A rough idea of when the problem started, so you pick the right entry. History timestamps are shown in your own local time. The Backups tab: an automatic schedule at the top, 30 days of restorable history underneath. 1. Open the Backups tab Go to Instances → your instance → Backups. The page opens with two cards, Backup schedule and Backup history. Refresh re-reads both; Back to Instance returns you to Overview. A message reading You don't have permission to manage backups on this instance. means you are a sub-user without the Manage backups permission, which the owner grants under Members. Note: One permission covers the whole tab: anyone who can change the schedule can also restore and delete, so grant it only to people you trust with the persistence data. Every schedule change, restore and delete is attributed in the Audit Log — see staff permissions and API keys. 2. Choose a backup frequency The Backup schedule card holds one dropdown. Pick a value and click Save; a toast confirms it, such as Backup frequency set to Daily. Discard appears beside Save while a change is unsaved. OptionWhat it doesOffNo backups at all. Existing entries stay until retention removes them.Every 6 hoursFor a busy server where six hours of base building is a lot to lose.Every 12 hoursA good default for most community servers.DailyEnough for a low-population or PvE server.WeeklyOnly useful alongside your own manual copies. The interval runs from the last backup attempt, not against the clock, so Daily means about every 24 hours and drifts slightly forward each day; there is no field to pin it to a set hour. Backups need no downtime either: the node takes a Volume Shadow Copy snapshot first, so players.db is captured cleanly while DayZ holds it open and players are online. Careful: Off means exactly that. Turn backups off and there is nothing on the node to restore from when someone gets griefed three days later. Note: A banner reading Backups are not fully configured on this node yet. means your choice is saved but will not produce entries until an administrator finishes enabling backups on that node. Open a ticket if it persists. The five backup frequency presets. The interval runs from the last backup, not from a fixed hour. 3. Know what is in a backup, and what is not A backup captures your mission folder under mpmissions — persistence and mission config — split into three independently restorable categories: Players DB — player characters and inventory: players.db plus players.db-wal and players.db-shm.World Data — built structures, vehicles and other persisted world state. Everything else in the storage_* folder.XMLs & JSONs & other(s) — mission-level config: types.xml, events, spawn configs and the rest of the mission folder outside storage_*. mpmissions/ dayzOffline.chernarusplus/ one "world" in the restore tree db/ XMLs & JSONs & other(s) cfgeconomycore.xml XMLs & JSONs & other(s) cfgspawnabletypes.xml XMLs & JSONs & other(s) storage_1/ players.db Players DB players.db-wal Players DB players.db-shm Players DB data/ World Data Every mission folder under mpmissions is captured separately, so if you have switched maps you will see more than one world in the restore tree. Careful: Not in a backup: your mods, your logs under profiles, and serverDZ.cfg. The config is safe anyway because the panel writes it from the typed Instance Settings editor, but a mod that keeps its state under profiles is outside the backup’s scope — copy that folder down yourself over SFTP. 4. Read the backup history Backup history lists entries newest first. On a new instance it reads No backups yet. They'll appear here once the schedule runs.; the first arrives after one interval has elapsed. Each row shows a status pill, the creation time in your local timezone, the compressed size, and whether it was Scheduled or Manual. Everything the schedule produces is Scheduled; Manual only appears on an entry created from our side, for instance while a support ticket is being worked. StatusMeaningAvailableFinished and restorable. The only status Restore accepts.CreatingSnapshotting and zipping now. Becomes Available on its own.RestoringA restore from this entry is running. The backup file is not modified, so the row returns to Available either way.DeletingRemoval is queued, either because you asked or because retention aged it out.FailedCould not be created. The reason is appended after the size. Restore opens the restore panel — greyed out unless the entry is Available and the server is stopped, and hovering it names the blocking condition. Delete removes the backup file from the node. Entries are deleted automatically 30 days after creation, so Every 6 hours carries roughly 120 restore points and Weekly roughly four. Data loss risk: Delete is permanent, and the confirmation says so: This cannot be undone. There is no recycle bin and we cannot bring a deleted backup back. Use it to clear Failed entries, not to tidy up. Backup history rows: status pill, local timestamp, size, trigger label and the per-entry Restore and Delete buttons. 5. Stop the server before you restore While the instance is up, Backup history shows a banner reading The server is running. Stop it before restoring a backup. and every Restore button is disabled with the tooltip Stop the server first. That is not a formality. A running DayZ server holds players.db open and flushes persistence as it goes and again on shutdown, so restoring underneath it either fails on a locked file or gets overwritten the moment the server next saves — burning the outage without fixing anything. The panel and the node both refuse outright. Click Stop on Overview. If players are online, use Controlled Restart first so they are warned and can log out somewhere safe — restarting without rollbacks explains what an abrupt kill costs them. Back on Backups, the banner clears a few seconds after the instance reports Stopped. Careful: Plan the outage. The server stays down until you start it again, and a large World Data category on a long-lived server takes a while to unpack. While the instance is running the Restore buttons stay disabled — restoring live persistence would be refused or overwritten. 6. Restore only the parts you need Click Restore on the entry you want. A panel headed Restore backup opens, subtitled with that backup’s timestamp, and states plainly: Choose which parts to restore. Existing files will be overwritten. Below is a checkbox tree, one group per world. The group header is the mission folder name — dayzOffline.chernarusplus — with (Persistence) beside it, and ticking it toggles all of its categories. Each category shows its size and file count, so you can see that Players DB is a few megabytes while World Data may be hundreds. Data loss risk: Everything starts ticked. Untick what you want to keep, because whatever stays ticked is overwritten from the backup and the live copy is gone. Leaving Players DB ticked when you only meant to fix a base rolls every character back to that timestamp — inventory, position, health, all of it. That separation is the whole point: A group blew up someone’s base overnight. Tick World Data only: structures and vehicles go back to last night, and everyone keeps the character and gear they have now.A bad types.xml edit broke your economy. Tick XMLs & JSONs & other(s) only: loot config reverts, no base or character is touched. Editing types.xml and the loot economy covers avoiding the next one. The confirm button counts your ticks — Restore 1 part for one category, Restore 3 parts for three — and stays disabled until a box is checked. Cancel changes nothing. Note: A restore overwrites the files that are in the backup and leaves anything else alone; it is not a wipe-and-replace of the directory. A genuinely clean slate is a wipe, which is not a panel operation — open a ticket. The restore panel: tick one world’s World Data alone to undo griefing without rolling back player characters. 7. Watch it finish, then start the server Confirming queues the work on the node. The pill switches to Restoring and a progress strip appears under that row, polled every second or two until it settles on Done or Failed; Dismiss clears it. The backup file is never modified, so the row returns to Available either way — and if it failed, the reason is appended after the size. Read that before retrying. Now click Start on Overview and verify before announcing you are back: Server Status reads Running, Server FPS reports a number, and the thing you restored looks right in game. If you restored Players DB, tell players first — a silent character rollback reads as a bug. 8. Keep your own copy for anything older than 30 days This tab is 30 days of node-side history, not an archive, and its entries are only ever restored in place. Two situations need more: A copy off the node. Pull mpmissions/<world>/storage_* down over SFTP. That is the whole persistence set, and it is yours to keep — see making and downloading a manual backup over SFTP.Something risky right now — an economy rewrite, a mod that touches persistence, a map change. Do not wait for the schedule: stop the server, copy the mission folder down, then make the change. Connecting with SFTP covers credentials and clients. Note: SFTP is the route for anything large either way: the web File Browser caps uploads at 300 MB against SFTP’s 2.5 GB, and a mature storage_1 folder can be well past the smaller limit. A restore here only reads backups this panel created, so an archive from another host goes in over SFTP too — see migrating a DayZ server to a new host. Troubleshooting The Restore button is greyed out and I cannot click it Why it happens. Only two things disable it: the entry is not Available, or the instance is running. Restoring into live persistence would be blocked by open file handles or silently overwritten. How to fix it. Hover the button — the tooltip names the reason, either Stop the server first or Backup not available. Stop the instance on Overview and wait for the banner to clear, or pick an entry whose pill reads Available. My backup history is empty and no backups are being created Why it happens. In order of likelihood: the schedule is Off; the first interval has not elapsed on a new instance; or the node has not finished having backups enabled, which the panel says with a banner reading Backups are not fully configured on this node yet. How to fix it. Check the dropdown is not Off and Save if you change it. On a new instance give it one full interval — Daily means waiting a day for the first entry, so choose Every 6 hours if you want one sooner. If the node banner is showing, open a ticket; your schedule is already saved. A backup entry says Failed and it is still sitting in the list Why it happens. The node could not complete the snapshot or the zip, and the reason is appended after the size. Retention only prunes entries that reached Available, so a Failed row is never aged out. How to fix it. Read the note, then Delete the row to keep the list readable. The schedule carries on and tries again at the normal interval, so one failure needs no action. If several in a row fail, open a ticket with the note text. I restored a backup but players say their bases and stashes are still gone Why it happens. Almost always an unticked category. Bases, vehicles, tents and buried stashes are World Data, not Players DB — restoring only the players database brings characters back without touching a structure. How to fix it. Stop the server again, open Restore on the same entry and tick World Data this time. Take both categories from one backup rather than mixing timestamps, or you end up with characters from one moment and a world from another. The Backups tab is missing from my instance tab bar Why it happens. The tab bar is permission-gated per instance, and without Manage backups the tab is not rendered at all — which is why it looks absent rather than locked. How to fix it. If you own the instance, check you are signed in to the right account. Otherwise ask the owner to add Manage backups to your grant under Members. Frequently asked questions Can I take a backup right now, on demand? Not from the Backups tab — the schedule is the only trigger and there is no create-now button. For a snapshot at a specific moment, such as just before a risky edit, stop the server and copy mpmissions/<world>/storage_* down over SFTP instead; making a manual backup over SFTP covers it. Can I download a backup from the panel? No. Automatic backups live on the node and are only ever restored in place, so there is no download button. For a copy on your own disk, take it yourself over SFTP — which also removes the 30-day limit, since a file you have downloaded is yours indefinitely. Does my server have to be offline for a backup to be taken? No. The node takes a Volume Shadow Copy snapshot before it reads anything, so players.db is captured consistently while DayZ holds it open and players are online. Scheduled backups need no downtime; restoring is the operation that requires the server stopped. How long are backups kept, and can I keep them longer? Thirty days from the moment each backup was created, after which it is deleted automatically. The window is set per node and is not adjustable per instance, so anything you need beyond a month has to be downloaded over SFTP and stored yourself. Does the Daily option run at a fixed time of day? No — the interval runs from the last backup attempt rather than against the clock, so Daily means roughly every 24 hours and drifts a little forward each day. There is no field to pin it to a particular hour, and the Scheduler tab offers no backup task either; it handles restarts, start/stop and RCON messages only. Will restoring roll back player characters as well as bases? Only if you tick Players DB in the restore panel. Every category starts ticked, so untick it deliberately when you want to fix the world and leave characters where they are — that separation is the main reason to use category-level restore rather than putting a whole backup back. Related guides Getting started with the control panelMaking a manual backup over SFTPRestarting without rollbacks