Terms, Concepts, and Best Practices
Zmanda Classic (ZC) is built on Amanda Community - The Open-Source network backup and archival tool of choice for most major Linux Distros. Given ZC's heritage, many - but not all - of the concepts, terms, and mechanisms stem from Amanda. Let's dive in!
Terms and Definitions
Zmanda Server - Comprised of two components: The Zmanda Management Console, and one or more Backup Servers. The components are customer-hosted and can be on-premise, on cloud, or take a hybrid approach. All components (including clients) need to be on the same network (i.e. different environments must be connected via VPN)
Zmanda Management Console (ZMC) - The browser-based GUI used to configure and manage Zmanda Backup jobs and perform administrative tasks. You may also see this referred to as the Zmanda Control Plane
Backup Server - The server component used for data processing and job execution. Backup servers can be clustered together under a single ZMC to provide scaling
Zmanda Client/Agent Software - The software that allows the Zmanda Server to talk to the source being backed up. Available for Windows and Linux servers and workstations. The Windows and Linux client software also gives the ability to perform client-side encryption and compression
Agentless Backups - Refers to backups of VMs on VMware and Hyper-V platforms
Disk List Entry (DLE) - A term from Amanda that refers to the specific source paths and objects being backed up. They are typically referred to as sources throughout the Zmanda Classic documentation
Concepts
Since Amanda is the foundation of Zmanda Classic, the latter uses many of the same mechanisms and tools to run jobs as the former.
4 Phases/Components of a Backup Job:
Planner - Plans the backup including performing sizing estimates and scheduling
Taper - responsible for writing backup data to storage media. Multiple taper processes may run concurrently.
Dumper - responsible for dumping data from the client to the server. Only one dumper process runs at a time on Windows clients, and multiple dumper processes can run concurrently on Linux
Driver - Orchestrates and manages the flow of data for the entire backup process
Backup Format
Zmanda uses open formats to back up data. In most cases, Zmanda uses tar but can be configured to use other open formats like star or dump.
An important note is that the data for each configured source will be encapsulated in its own tar file.
This means that if you specify source paths such as / in the case of Linux or C:\ in the case of Windows when you need to restore a single subdirectory or file, the entire tar file will be downloaded from storage to a temporary location on the backup server where the item selected for restore will be extracted and restored to the target system. The temporary location on the backup server will then be cleared. For this reason, it is best to break larger sources into smaller backup sets, thus improving restore times.
Backup Sets
A Backup Set is a grouping of data sources, a single storage target, and a single schedule. Backup sets may contain as many sources as desired, however, an important consideration is that you cannot perform concurrent restores for sources that come from the same backup set. For this reason, it is best to create multiple backup sets with just a few (1-5) sources each.
You may use the same schedule for many backup sets, as well as the same storage target. Once you configure a schedule for a backup set, you can change it in the future. The same is not true of storage targets; once storage is configured, it cannot be changed. If you wish to back up data to two different storage targets, you may use the vaulting feature, or you may also create a new backup set that is configured to back up to a different storage target. The former is best for copying data from disk to tape or from disk to cloud and retaining it indefinitely. The latter simply performs a new backup from the source to the storage medium of choice and will incur additional I/O load on your source device and on the network.
It is also possible to add the same source to multiple backup sets, allowing for different schedules and storage configurations for the same source. If you choose to do this, be aware that you will be unable to restore an incremental backup from one backup set on top of the full backup of another backup set.
Microsoft SQL databases require a linear restore process, so it is best to place SQL sources in only one backup set.
Summary of Best Practices
Ensure that your Backup Server, ZMC, and Zmanda Client Devices are all on the same network (using VPN if needed).
The preferred deployment method for a complete Zmanda Server is to use the Zmanda Backup Appliance - a VMware virtual appliance with the Zmanda Server software already installed.
Break large sources into smaller sources. For example, if you wish to backup the entire C Drive in Windows or root directory in Linux, create individual sources for each of the subdirectories instead of simply putting the drive path. This will improve restore times for individual files and folders
Reduce the number of sources in each backup set. This will allow you to perform more parallel restores
Do not add SQL databases to multiple backup sets. You will see restore issues due to the strict linear nature of the restore process
Last updated