Hi everyone. I've been tasked with setting up a new Sophos XGS 2100 at my company, and I'm trying to get our IT processes in order. I come from more of a project management and SaaS background, so networking hardware is a bit new for me.
I want to start using version control for our firewall configuration. I've seen this mentioned as a best practice in a few places, but I'm stuck on the very first step. I can't seem to figure out how to export a full, complete configuration backup file from the XGS web admin console. I see options for backups, but I'm not sure which one is the right one for this purpose, or if I need to do something via SSH.
Could someone walk me through the exact steps to get a file I can store in our version control system? I'm specifically on the latest firmware (SFOS 19.5, I believe). Is it just the "Backup" option under "Backup & Firmware"? And is that file human-readable for diffing, or is it encrypted? Any gotchas I should know about?
Thanks so much for helping a newcomer out
Great question, and kudos for bringing version control to your configs. That's a solid practice.
You're on the right track. The "Backup" option under "Backup & Firmware" is what you want. It creates a single .xml file containing the full configuration. It's technically human-readable XML, but it's a dense export not really meant for manual diffing. The file is not encrypted by default, but it *does* contain potentially sensitive data like passwords for certain services, so treat it as such.
One gotcha: The backup file is tied to the exact SFOS version. You can't restore a v19.5 backup to a firewall running v19.0, for example. Just be mindful of that in your version control notes.
For diffing, you'll likely want to use a proper XML diff tool in your pipeline, as the line ordering can change between exports. Some folks run it through an XML formatter first to get consistent formatting for cleaner diffs.
Stay factual, stay helpful.
While you're right to focus on getting the file, putting an unprocessed Sophos backup directly into version control is a terrible idea. That XML dump contains every password hash, shared secret, and pre-shared key. You're creating a single point of catastrophic failure for your entire network security.
The actual best practice is to treat that backup as a master source, then write a script to parse it, strip all sensitive fields (look for anything with 'password', 'secret', 'key', 'psk' tags), and *then* commit the sanitized version. You'll need a separate, encrypted vault for the actual backup files.
The version lock mentioned is real. You can't even restore a 19.5.1 backup to 19.5.0 sometimes.
Show me the data
Good to hear from someone else who's moving from SaaS into the hardware side. I'm in a similar boat with my role.
You've got the right menu - it's under Backup & Firmware. Just click 'Backup' and it'll generate that XML file for download. I've been testing this process myself.
A practical thing I ran into: the file name includes a timestamp by default. That's fine for a one-off, but for automated version control you might want to script the download and rename it to something consistent, like 'firewall-config-primary.xml', so your diffs are cleaner.
Since we both come from that SaaS background, how are you planning to handle the pipeline? Like, are you triggering these backups manually or looking at an API?