Zmanda — central backup without locking into one storage type
Zmanda is a backup platform built for environments where there’s more than one server to worry about — usually a mix of Linux, Windows, maybe a couple of macOS machines thrown in. It came out of the Amanda open-source project, so the core format is open and doesn’t lock backups into a single vendor’s tools.
The server runs on Linux and pushes backup jobs to agents installed on client systems. Storage can be anything from a disk array in the same rack to a tape library or a bucket in AWS S3, Google Cloud, or Azure. It also knows how to deal with databases — MySQL, PostgreSQL, Oracle, SQL Server — backing them up in a consistent state so you’re not restoring corrupted data later.
Capabilities
| Feature | Description |
| Cross-Platform Agents | Linux, Windows, macOS — same core logic on all |
| Central Job Control | One place to schedule and monitor backups |
| Storage Flexibility | Disk, tape, or cloud without changing the setup much |
| Database-Aware | MySQL, PostgreSQL, Oracle, SQL Server support |
| Backup Types | Full, incremental, differential |
| Encryption | Client-side so data is protected before it leaves the host |
| Compression | Shrinks backup size, saves storage and bandwidth |
| Open Formats | Based on Amanda — no proprietary archives to decode later |
Deployment Notes
Needs a Linux server for the management console. Each client machine gets its own agent, so installation and initial config take time if there are a lot of endpoints. Tape libraries work well, but cloud targets need credentials and a stable link — retries can slow jobs on weak connections. Database plugins must be tested with both backup and restore before signing off on production use.
Quick Start (Linux Server)
1. Install Zmanda Management Console.
2. Deploy agents to every system you need to back up.
3. Create backup sets with the required paths or databases.
4. Pick storage: local disk, tape library, or cloud bucket.
5. Set schedules and retention rules.
6. Run a full backup first, then switch to incrementals.
Where it’s useful
– Offices or datacenters with mixed OS servers.
– Companies still using tape alongside newer storage.
– Environments with critical databases that can’t afford inconsistent backups.
– Hybrid setups where part of the backup goes to the cloud.
– Situations where compliance requires long retention with encryption.