Hey everyone, new-ish to managing a few SonicWall appliances (mostly TZ series) and trying to get our processes tightened up.
I've seen the built-in backup to USB/FTPS options in the GUI, but I'm looking for something more hands-off and centralized. Manually exporting configs before a firmware update feels... risky and forgettable. We're a small team, so automation is key.
What's the best practice for automated, scheduled config backups? I'm poking at the possibilities:
* Is the SonicWall API reliable for this? I found some mentions of `config/export` but the details seem sparse.
* Are you all using scripts (Python, PowerShell) to pull via SCP or FTPS on a schedule?
* Any gotchas with backing up while the appliance is under heavy load?
I'm especially curious about storing versioned backups. If a bad config gets pushed and backed up, we'd want to roll back to the last known good state, not the broken one. How are you handling that piece? Separate storage with date-stamped files?
Thanks in advance for any workflow tips or scripts you're willing to share. The documentation covers the "how" but not really the "how to do it well." 🙏
I'm Alex, and I manage the IT systems for a ~100 person software company. We run a mix of SonicWall TZ and NSv firewalls, and I've been using automated config backups for about three years now to keep things safe.
When I evaluated this, I looked at four main areas that matter for a small team setting it and forgetting it.
1. **Reliability and Recovery Integrity:** The worst time to find a backup is corrupted is when you need it. The native export via FTPS with a scheduled job in the firewall itself is the most reliable method I've found. It's a direct stream of the config file. Scripted methods using the API can occasionally timeout during heavy load, leaving you with a partial file. We back up to a secure internal server, not USB, for this reason.
2. **Versioning and History Depth:** You need to see *what* changed, not just have the latest file. We use a simple script on our backup server that renames every downloaded config with a timestamp (e.g., `TZ600_2024-10-25_15-30.bak`). We keep 90 days of daily backups. For the "bad config" problem you mentioned, we also take a manual backup right before any planned change. That manual snapshot is kept separately for a year.
3. **Operational Overhead:** The built-in scheduler is low overhead but inflexible. Using it means your backups live on the firewall's configured FTPS/SFTP server, and you manage retention there. A mid-ground approach is a minimal Python script using the `requests` library to hit the `config/export` API endpoint; this adds maybe 2-3 hours of setup but lets you centralize logging and alerting if a backup fails. Pure PowerShell with SCP worked but was fussier with key management in my experience.
4. **Security and Access:** This is a full device config. Automating this means creating a service account with admin rights. The API method requires storing those credentials securely in your script or runner. The FTPS method requires storing those credentials on the firewall. The latter felt slightly more contained to me. We use a dedicated, restricted account for backups only, and the backup files themselves are encrypted at rest.
My pick is the native scheduled export to a secure, internal FTPS/SFTP server, augmented by a separate versioning script on that server. For a small team wanting a set-and-forget system, it's the most stable. If you need tighter integration with an existing config management tool or want to trigger backups before/after other automated tasks, then the API path is better. To decide, tell us if you have a central server you can use as a backup target already, and if you're more comfortable maintaining a firewall schedule or a small Python script.
Let's keep it real.
The API's flakiness under load is real. Your fear about backing up a bad config is the real problem, though. Storing date-stamped files is just a filing system; it doesn't tell you which one is good.
You need something that commits the config to a repo only after a known-good state change, like after a maintenance window. Blind cron jobs that pull the config at 2 AM will happily archive that midnight routing blackhole you just created. I version with git, but only trigger the backup from a pipeline that runs after our change-control process completes, not on a simple schedule.
For a small team, the built-in FTPS scheduled job to a central server is fine for disaster recovery. But for true rollback, you're right to worry. How do you plan to define "known good"? That's the harder piece.
The API is brittle. Scripted pulls fail when the appliance is busy.
Use the built-in scheduled export to FTPS. It's more reliable than any external cron job trying to pull. Have it dump to a secure server with versioned storage, like a git repo or an S3 bucket with object versioning.
Your real problem is identifying known-good configs. Automated versioning captures every mistake. Separate your backup triggers: scheduled FTPS for disaster recovery, and a manual/CI-triggered export to a "golden" repo after verified changes.