> For the complete documentation index, see [llms.txt](https://docs.zmanda.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zmanda.com/overview-and-concepts.md).

# Overview and Concepts​

This page includes definitions used throughout our documentation and other high-level information about how Zmanda Pro operates.

### Terms and Definitions <a href="#terms-and-definitions" id="terms-and-definitions"></a>

**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](https://docs.zmanda.com/guide/encryption-and-key-management) 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.&#x20;

<figure><img src="https://1846973900-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPSSsZ7NTpC1G3n2CzF9L%2Fuploads%2FYYPKHA3Mch3X8dFLZm1f%2FStorage%20Vault%20Example.png?alt=media&amp;token=896d49eb-7ef2-492e-a298-0f627fb89e64" alt=""><figcaption><p>Example: Storage vaults can be logical partitions of the same storage medium. There should be a 1:1 mapping of users to devices. Each storage vault can only be accessed by a single backup user, but each backup user can have multiple storage vaults. Storage vaults may also be on different media (not shown). Users may be end users, or they may map to specific devices. Admin users can configure and manage all of these details.</p></figcaption></figure>

### **Server Deployment Options**

You may deploy Zmanda Pro in one of three ways:

<table data-full-width="false"><thead><tr><th width="217">Deployment Option</th><th>Details</th></tr></thead><tbody><tr><td>Cloud (SaaS)</td><td><ul><li>No server licensing fee</li><li>Support access can be granted to the Zmanda support team for faster time to resolution</li><li>Start backups in minutes and save on administrative overhead</li><li>Backup data stays within your environments</li><li>Automatic updates</li><li>Hosted on Microsoft Azure</li><li>Option for managed cloud storage (Zmanda Cloud Storage)</li></ul></td></tr><tr><td>On-Premise, Online</td><td><ul><li>Requires a server licensing fee</li><li><a href="https://www.zmanda.com/pricing/">Business Plus</a> only</li><li>Good for environments where strict data sovereignty is a concern, but air-gap isn't required</li><li>Manual updates</li><li>Less Zmanda Sales team intervention when license count updates are required compared to On-Prem, Offline</li><li>Otherwise, functionally identical to SaaS</li><li>Server DR is available</li><li>Storage replication is available</li></ul></td></tr><tr><td>On-Premise, Offline</td><td><ul><li>Same as On-Prem, Online, but made for completely air-gapped environments where internet connectivity is not permitted</li><li>Requires Zmanda Sales team help to update license counts and upgrade the server software</li></ul></td></tr></tbody></table>

### Zmanda Pro Console​ <a href="#zmanda-pro-console" id="zmanda-pro-console"></a>

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.&#x20;

<div data-full-width="false"><figure><img src="https://1846973900-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPSSsZ7NTpC1G3n2CzF9L%2Fuploads%2FeyfrvvTEUjpHq0vIfGLA%2FScreenshot%202023-12-18%20172825.png?alt=media&amp;token=18c306d0-84ec-488c-9975-815feb282ec4" alt=""><figcaption></figcaption></figure></div>

### **Security & Encryption**

See [here ](https://docs.zmanda.com/guide/encryption-and-key-management)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.&#x20;

### **Device Registration**

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.&#x20;

### Backup Approach​ <a href="#backup-approach" id="backup-approach"></a>

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.

### **Custom Commands**

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.&#x20;

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:

1. BACKUP\_TOOL\_USERNAME

* **Type:** String

2. BACKUP\_TOOL\_DEVICE\_ID

* **Type:** String

3. BACKUP\_TOOL\_JOB\_ID

* **Type:** String

4. BACKUP\_TOOL\_JOB\_STATUS

* **Type:** Integer
* **Comment:** Job status is accessible exclusively within After commands.