Overview and Concepts
This page includes definitions used throughout our documentation and other high-level information about how Zmanda Pro operates.
Last updated
Was this helpful?
Zmanda Pro
This page includes definitions used throughout our documentation and other high-level information about how Zmanda Pro operates.
Last updated
Was this helpful?
Admin User: A user with elevated privileges who can create backup users, define backup policies, access job history, configure email notifications, and manage backup and restore operations.
Backup Users (Sometimes referred to simply as Users): Accounts used to log into devices with the Zmanda Pro client software installed. They can be mapped to end-users, or they can be mapped to specific devices. For example, a user may be created for each employee in a company, or, separate users can be created for each server managed by an IT team. In both cases, we recommend a 1-to-1 mapping of users to devices for security and performance reasons.
The password for each backup user is essential for encrypting backup data. See here for more information.
Devices: Systems with the Zmanda Pro client software installed, which can be based on Windows, Linux, or macOS. These devices perform deduplication, encryption, compression, and data transmission. Each device should be associated with a single backup user.
Protected Items: Data sources, including filesystems, shares, databases, disk images, VMs, M365, or other supported sources.
Storage Vaults: Storage locations for backed-up data, serving as the units for deduplication and encryption. Vaults can be provisioned from various storage media, including local disks, mounted filesystems, and cloud storage. It's important to note that data deduplication does not occur across different Storage Vaults. Storage vaults are only accessible by a single backup user.
You may deploy Zmanda Pro in one of three ways:
Cloud (SaaS)
No server licensing fee
Support access can be granted to the Zmanda support team for faster time to resolution
Start backups in minutes and save on administrative overhead
Backup data stays within your environments
Automatic updates
Hosted on Microsoft Azure
Option for managed cloud storage (Zmanda Cloud Storage)
On-Premise, Online
Requires a server licensing fee
Business Plus only
Good for environments where strict data sovereignty is a concern, but air-gap isn't required
Manual updates
Less Zmanda Sales team intervention when license count updates are required compared to On-Prem, Offline
Otherwise, functionally identical to SaaS
Server DR is available
Storage replication is available
On-Premise, Offline
Same as On-Prem, Online, but made for completely air-gapped environments where internet connectivity is not permitted
Requires Zmanda Sales team help to update license counts and upgrade the server software
You can access the Zmanda Pro console by logging in with an admin or user account, allowing you to perform remote backups and restores. Logging in as an admin lets you configure jobs across different users. Logging in as a backup user lets you control jobs only for that user.
Windows clients and graphical Linux clients include a Zmanda Pro GUI directly on the client. Only backup user credentials can be used to log in to this interface.
See here for more information on how Zmanda handles encryption. Other security features of Zmanda include SSO integrations (OpenID Connect-based providers), customizable email reporting, webhook monitoring, MFA via TOTP or FIDO2, an optional zero-trust security model, and more.
Devices must be registered to an individual backup user before storage vaults and protected items can be configured. Registration may be done directly on the client system or remotely (silent installation). We recommend a 1:1 mapping of users to devices for the best performance and security.
Zmanda Pro employs a backup strategy by initially dividing data into variable-sized chunks, which are individually compressed, encrypted, and then uploaded. The process utilizes data-dependent chunking, effectively breaking down a file into consistent chunks even in the presence of random inserts.
For a given backup job, a list of files and the required chunks for their reconstruction are created. Subsequent incremental backup jobs recognize existing chunks on the server, eliminating the need to re-upload duplicate chunks.
Key features of this chunking technique include:
Both the oldest and most recent backup jobs can be restored at the same speed.
Duplicate data doesn't require additional storage due to identical chunks (deduplication).
There is no requirement to re-upload the entire file, regardless of the number of backup jobs.
The server doesn't need to be trusted to decrypt data.
Zmanda Pro allows you to execute commands before and after backup jobs, allowing you more control over backup workflows. Possible uses include running commands to dump databases, taking filesystem snapshots, running rsync or rclone scripts, and more. Commands are executed on the device where the agent is installed.
Commands can be configured on three levels:
Protected Items: Execute commands tailored to individual items, such as dumping a database before its backup.
Storage Vaults: Implement custom commands for storage vaults, like performing unique network authentication procedures.
Schedules: Automate actions linked to schedules, enabling tasks like shutting down your computer after a backup.
Command Execution Sequence: During a backup job, commands are executed in this order:
Schedule Before
Protected Item Before
Storage Vault Before
Backup
Storage Vault After
Protected Item After
Schedule After
Shell Built-ins for Enhanced Flexibility: Expand your command capabilities by incorporating shell built-ins, ensuring compatibility with your operating system through either cmd.exe or /bin/sh execution.
Environment Variables
When executing custom before or after commands, the following environment variables are available:
BACKUP_TOOL_USERNAME
Type: String
BACKUP_TOOL_DEVICE_ID
Type: String
BACKUP_TOOL_JOB_ID
Type: String
BACKUP_TOOL_JOB_STATUS
Type: Integer
Comment: Job status is accessible exclusively within After commands.
