Search the Community
Showing results for tags 'SFTP'.
Found 2 results
-
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
-
Everything you need to connect to your DayZ server over SFTP sits on one page: open your instance, click the SFTP tab, and the Connection card gives you the Host, the Port (2022) and your Username, each with a Copy button. The Password card below holds a dedicated SFTP password, separate from your panel login. This guide sets up WinSCP and FileZilla step by step, explains the unusual username format, and covers the two mistakes that cost real time: editing files while the server runs, and regenerating the password without updating saved sessions. On this page Open the SFTP tab and read the Connection cardGenerate or copy your SFTP passwordConnect with WinSCPConnect with FileZillaFind your way around the four foldersUpload and download without breaking anythingGive staff SFTP access without sharing your passwordTroubleshootingFrequently asked questions Before you start A provisioned instance and a panel account with the Allow SFTP access permission on it. Instance owners have it automatically.An SFTP client. This guide uses WinSCP and FileZilla, both free on Windows.Outbound TCP on port 2022 allowed by your own network — some corporate and school networks permit only 80 and 443. The SFTP tab holds every value your client needs — host, port 2022, username and a dedicated SFTP password. 1. Open the SFTP tab and read the Connection card Go to Instances → your instance → SFTP. The header reads SFTP Access followed by your instance name, and the Connection card lists three values, each with its own Copy button: Host — the machine your instance runs on. Depending on the node this is either a hostname or the same IP you connect to in game.Port — 2022, not the usual 22. Leave your client on the default and it will fail to connect.Username — your panel username, a dot, and eight hexadecimal characters, for example yourname.4f2a91c0. That trailing block is the first eight characters of the instance’s internal id, and it is how the SFTP server knows which instance you want. One account with three servers therefore has three different SFTP usernames. Copy it verbatim — a login built from your panel username alone is rejected. Note: Open in SFTP client hands the host, port and username to your computer’s default SFTP application, so you only type the password. If nothing happens when you click it, set the client up manually as below. 2. Generate or copy your SFTP password Scroll to the Password card. Its badge reads Set or Not set, and the subtitle gives the date it was last set. The first time you open this tab with no password on file, the panel generates one immediately and confirms with SFTP password generated. — so usually there is nothing to do but reveal it. Use Show to unmask the value and Copy to take it, then store it in your password manager. For a fresh one, click Regenerate password. Careful: This password belongs to your panel account, not to one instance. Regenerating takes effect immediately and stops the old password working on every instance at once, so saved sessions in WinSCP or FileZilla and any script that pulls backups fail until you update them. Two other states exist. Not set with an empty field means none exists yet — click Generate password. The message This password was set before it could be shown here. Generate a new one to view and copy it. means yours predates the panel storing a displayable copy: it still works if you know it, but cannot be shown. Note: This is not your admin or RCON password. The SFTP tab is the only place it lives. The SFTP password is per panel account — regenerating it invalidates the old one everywhere at once. 3. Connect with WinSCP WinSCP opens its Login dialog on launch; if it does not, use Session then New Session. Fill in four fields: FieldValueFile protocolSFTPHost namethe Host from the Connection cardPort number2022User namethe full Username, dot and eight characters includedPasswordyour SFTP password Click Save if you want the session kept, then Login. The first connection asks you to accept the server’s host key fingerprint — normal, and once per machine. You then land in a directory holding your four folders. Note: If WinSCP fails without ever prompting for a password, an SSH agent is offering keys and burning the five attempts the server allows. Under Advanced → Authentication, clear the public-key and agent options. WinSCP configured for a DayZ server: protocol SFTP, port 2022 and the per-instance username. 4. Connect with FileZilla FileZilla’s Quickconnect bar defaults to plain FTP, which will not work here, so use the Site Manager: Open File → Site Manager and click New site. Name it after your instance.Set Protocol to SFTP - SSH File Transfer Protocol.Paste the panel’s Host into Host, and 2022 into Port.Set Logon Type to Normal, then paste the full Username into User and your SFTP password into Password.Click Connect and accept the host key when prompted. To avoid storing the password, choose Ask for password as the logon type instead. 5. Find your way around the four folders SFTP shows the same four shares as the panel’s File Browser, and nothing else: profiles — server logs (.ADM, .RPT, script_*.log) and profile data: full log history, rather than the live tail.mpmissions — the mission folder, holding both your economy XMLs and your persistence.config — serverDZ.cfg, the BattlEye keys directory, and the whitelist.txt, ban.txt and priority.txt lists.mods — installed Workshop mods. Persistence lives at mpmissions/<world>/storage_*/. players.db (with its -wal and -shm companions) holds every character and inventory; the rest of the folder holds built structures, vehicles and other world state. Pull these down before anything risky — see taking a manual backup over SFTP. Loot and economy editing happens one level up, in mpmissions/<world>/: types.xml, events.xml, cfgspawnabletypes.xml. There is no GUI for these, so SFTP plus a text editor is the workflow — editing types.xml and the loot economy covers them. Note: The DayZ server executable and the BattlEye working directory are deliberately not exposed — your session root holds only the four shares. Every SFTP session lands in a root holding just four folders: profiles, mpmissions, config and mods. 6. Upload and download without breaking anything SFTP exists mainly to lift the size ceiling: the web File Browser accepts uploads up to 300 MB, SFTP up to 2.5 GB. Data loss risk: Never write to storage_* while the instance is Running. DayZ holds players.db open and rewrites the storage folder on shutdown, so an upload under a live server is either ignored or flushed away, and a partial write to an open database can corrupt every character. Stop the instance, wait for Stopped, then upload. The same logic applies more gently to configuration: serverDZ.cfg and the economy XMLs are read once at boot, so a mid-session edit does nothing until the next start. Careful: Executable and script types are rejected outright: .exe, .dll, .bat, .cmd, .ps1, .sh, .msi, .scr and .com. If a mod ships a helper program, open a ticket rather than renaming the file to get it past the filter. Two structural limits round it off. Renaming is blocked in config and mods, which hold template-managed files, so upload under the final name instead. And serverDZ.cfg, the keys directory, whitelist.txt, ban.txt, priority.txt and the top-level mod folders cannot be deleted at all — overwrite those. 7. Give staff SFTP access without sharing your password Because the password is tied to a panel account, handing yours to a helper gives them your whole account. Add them under Members instead and let them generate their own. Two layers apply. Allow SFTP access decides whether they can log in; the Files permissions decide what they can do once in. Read files is the floor — SFTP access without it is refused at login — while Write files adds upload, overwrite and folder creation, and Delete files adds deletion. The rights match the File Browser exactly, so SFTP is not a back door. A member without access sees You don't have SFTP access to this instance. Ask the instance owner to grant it from the Members page. Successful logins are recorded in the Audit Log under the SFTP category with the account and the file rights it was granted; client IP addresses are deliberately kept out. Note: API keys cannot read the SFTP details or set the password — both endpoints reject key authentication. These credentials are for humans signed in to the panel. Troubleshooting My SFTP client says authentication failed or invalid credentials Why it happens. One of three things: the username was typed without the dot and eight characters, the panel login password was used instead of the SFTP password, or the account lacks Allow SFTP access or Read files. The server returns the same generic failure for all three. How to fix it. Use Copy on the Username row and the Password card rather than retyping. If both are right, check those permissions in Members. The server allows five authentication attempts per connection, so a client offering SSH keys first can exhaust them first. SFTP worked yesterday and now the password is rejected on every server Why it happens. Someone clicked Regenerate password. The SFTP password belongs to the panel account, not one instance, so regenerating invalidates it everywhere at once — every saved session, plus any backup script using it. How to fix it. Open any instance’s SFTP tab, Show and Copy the current password, and paste it into each saved site. If nobody knows the current value, regenerate once more and update everything from that one value. The panel says my password was set before it could be shown here Why it happens. The password predates the panel keeping a displayable copy, so only the stored hash exists. It still works — the panel just cannot tell you what it is. How to fix it. Click Regenerate password, then Show and Copy the new value and update your clients. The old one cannot be recovered. Uploads fail with permission denied, or the file never appears Why it happens. Three limits look alike: the account lacks Write files, the file exceeds the 2.5 GB SFTP ceiling, or its extension is blocked (.exe, .dll, .bat, .cmd, .ps1, .sh, .msi, .scr, .com). A failed rename in config or mods is separate: those hold template-managed files. How to fix it. Check the extension first, then Write files in Members. For a rename, upload under the final name. Split any archive over 2.5 GB and reassemble it on the server. I edited types.xml or serverDZ.cfg over SFTP but the server has not changed Why it happens. The engine reads those files once, at boot, and a running server keeps the values it loaded for as long as it is up. How to fix it. Restart the instance — use Controlled Restart if players are on. For persistence the rule is stricter: stop the server before touching storage_*, because a running server rewrites that folder on shutdown and discards your upload. Frequently asked questions Is my SFTP password the same as my panel password? No. It is a separate credential, generated and shown only on the SFTP tab, and changing one has no effect on the other. Accounts that sign in through the community site with no local panel password get one the same way, so single sign-on never locks you out of file access. Why does my SFTP username have a dot and eight characters after it? Those eight hexadecimal characters identify the instance. The SFTP server has no other way to know which of your servers you want, so it reads the instance out of the username at login — hence a different SFTP username per instance, and the need to copy it exactly. Can I connect with plain FTP or FTPS? No. Only SFTP is offered, on port 2022, and the account is restricted to that protocol at the server, so FTP and FTPS fail even against the right host. This matters in FileZilla, whose Quickconnect bar assumes FTP: use Site Manager and select SFTP - SSH File Transfer Protocol. Can I use an SSH key instead of a password? No — authentication is by password only, and there is nowhere in the panel to register a public key. If your client tries keys first, turn that off in its site settings so it does not waste the five attempts the server permits per connection. Why can I only see four folders, and not the DayZ server files? Your session is confined to profiles, mpmissions, config and mods — the same shares the File Browser exposes. The game binaries and the BattlEye working directory sit outside that boundary, which is why the session root looks nearly empty. How large a file can I upload, and when should I use SFTP over the File Browser? SFTP takes single files up to 2.5 GB, against 300 MB in the web File Browser. Use the File Browser for quick XML tweaks and log reading, and SFTP for anything bulky — custom maps, large mod payloads, whole-folder uploads, and pulling your persistence down to your own disk. Related guides Getting started with the control panelMaking a manual backup over SFTPEditing types.xml safely
