Backup Sets
If you are new to Zmanda backup framework, we suggest you start with the 10-minute summary on Zmanda, followed by the backup overview. If you are here, we assume you have completed the previous three steps or are seeking to learn more about backup sets.
A backup set groups the sources you want to backup in parallel and creates a virtual data boundary to separate data between backup sets. A single backup set might suffice when you want to back up one or two servers to one destination. Multiple backup sets are helpful for configurations where 100's systems have different backup requirements. For example, on a network that includes servers with a high rate of data change and desktop systems that change data more slowly, you would probably want to create one backup set for the servers and another for the desktops.
The above diagram incorporates a 3-2-1 data backup strategy for two backup sets, high-rate data servers, and slow-moving desktop systems. A point to remember is that a backup set is hard-bound to a storage set. Please read our storage guide if you want to create multiple storage sets from one storage target.
On deleting a backup set, the ZMC control plane will have no record of backups completed by the backup set. The data backed up is retained on the storage medium unless you choose to purge the data on the deletion of the backup set.
Creating a Backup Set
Once you log in to your ZMC control plane, click on Backup Sets in the side menu. This takes you to the overview screen, where all your backup sets are listed. To create a backup set, click on the Add Backup Set button on the top right, and you will be offered a side panel with the below fields.
Select AE Server: Allows you to select a backup server that will run the backups. The servers listed here are all the backup servers linked to the ZMC cluster feature.
Select Storage: This allows you to select a storage device where you want to save your backups.
Select Schedule: This allows you to configure the backup window in which the backups should run by selecting the right schedule plan for your backup runs.
Name field: This allows you to specify a unique name for the backup set. Alphanumeric characters are permitted, with no spaces, and the characters cannot exceed more than 255 characters.
Description field: Description are optional and are intended to serve as a reminder as to what type of backups are included or where it is configured.
Comments textbox: Operational or maintenance notes can be added in the comments.
Configuring a Backup Set
Building a backup set is a 7-step process. To begin, click on the configure icon of the backup set you just created.
Step 1: Backup What
In this phase, you define the sources you want to back up. If a source is not visible in the list, you can link that source to the backup set by heading to the sources tab, clicking on the edit icon on the specific source, and populating the backup sets dropdown field. It's helpful to note that a source can be linked to multiple backup sets.
Once the source is visible on the backup what screen, it should look like the below. Select all the sources you want to back up, and click on continue.
Type: Labels the kind of source detected. It can range from file systems, databases, applications, or hypervisors.
Hostname: IP/hostname of the source.
Included Paths: Displays the directories selected for backup. This directory is specified in the directory path field while creating the source.
Client OS: Labels the operating system detected, which is running on the source.
Version: Identifies the version number of the ZMC/ZWC client on the source.
Encrypt / Compress: Type of encryption (server, client, AES 256) and compression (Client Fast, Client Best, Server Fast, Server Best, Client Custom, Server Custom) enabled on the respective source.
Status: Displays the current status of the source. Online, offline, or partial could be in one of three states, with partial being used when the source is successfully backed up on one run and failed on the other.
Step 2: Backup Where
It displays the storage destination, which will store all the data generated by the sources. To change the storage container, please exit this flow and click on the edit icon on the first screen to view the side panel from which you configured the backup set. Different options will be visible based on the storage medium selected, as listed below.
Disk Information
Disk offers the best restore times, as data is present locally on the Zmanda server or within the network. Any storage mediums like NAS or SAN can be used for backup, provided they are configured as storage containers and are discoverable from the Zmanda Server. Below are the fields visible if your storage set is configured for disks.
Device type: Identifies the storage medium on which your backups will be stored. It can range from disks, tape, or cloud endpoints.
Device name: This is the custom name entered by the admin to identify the storage set. You can change the name by heading over to the ZMC's storage configuration.
Taperscan: The order in which the ZMC control plane should search the tapes in the tape changer. Zmanda has to load a tape to identify the correct tape unless the barcode reader is available.
Comments: Optional text field where you can add any operational notes, which you can read at a later time by coming back to Backup Where.
Backups stored at: Absolute path on the storage set, where the backup files will be stored.
Partition Total Space: Total size of the disk medium, displayed in MBs.
Partition Free Space: Total free space available on the storage medium. Please ensure that you have adequate space available to store your backups.
Media used Space: The space currently used on the storage medium, displayed in MBs.
Tape Changer Options
For long-term vaulting of data, tapes are the ideal storage destination. Before running the backup set, please ensure the mt package is configured on the backup server, which is connected to the tape library. Below are the fields visible if your storage set is configured for tapes.
Device type: Identifies the storage medium on which your backups will be stored. It can range from disks, tape, or cloud endpoints.
Device name: This is the custom name entered by the admin to identify the storage set. You can change the name by heading over to the ZMC's storage configuration.
Taperscan: The order in which the ZMC control plane should search the tapes in the tape changer. Zmanda has to load a tape to identify the correct tape unless the barcode reader is available.
Comments: Optional text field where you can add any operational notes, which you can read at a later time by coming back to the Backup Where segment.
Slot Range: It lets you specify the slot ranges that ZMC will use as part of this backup set. You can select the ranges as "2-5" or "9-13".
Changer Device: You define where ZMC can locate the absolute path where the tape changer is mounted on the selected backup server.
Tape Drive Device: The tape drive that the backup set should use. Please note that Zmanda will use the mt command to manage the device. You can specify multiple tape drives for a backup set, allowing parallel backups to the tape changer. You can use the update and verify button to ensure the matching between the tape device name and the drive slot number is done correctly. Note that updating and verifying may take a long time to check each tape drive.
Auto Label Tapes: The 'Auto Label Tapes' radio button allows users to specify if the tapes should be auto-labeled by Zmanda. The default value is set to No, indicating the users are expected to pre-label the tapes intended for backups. As used tapes might contain data from other backup sets, they cannot be labeled automatically.
Ignore Barcodes: You can disable barcodes if the tape does not have barcode labels. We don't recommend this because it is difficult for Zmanda to keep track of tapes and media labels without barcodes, and users will have to track this on their own if the barcodes are not enabled.
Cloud Storage Options
An ideal storage destination if you don't want to maintain an on-prem storage infrastructure. Below are the fields visible if your storage set is configured for cloud.
Device type: Identifies the storage medium on which your backups will be stored. It can range from disks, tape, or cloud endpoints.
Device name: This is the custom name entered by the admin to identify the storage set. You can change the name by heading to the ZMC's storage configuration.
Comments: Optional text field where you can add any operational notes, which you can read later by returning to the Backup Where segment.
Taperscan: The order in which the ZMC control plane should search the tapes in the tape changer. Zmanda has to load a tape to identify the correct tape unless the barcode reader is available.
Location Restriction: The geographic region to which your backup data should be restricted. Ideally, you would want to select a data center closest to your backup server to reduce latency.
Backup stored at: The location on the cloud bucket where you will keep the backup data. You defined this when you created the storage set.
Secure Communications Checkbox: Enforces SSL while moving your data to and from the cloud storage bucket. We recommend enabling it for secure communications.
Speed per Thread: Users can throttle the network bandwidth for each upload and download thread. The speed limits apply only to the selected backup set.
Treads per Upload or download: Users can control the number of threads used simultaneously to upload the backup and download the restores from the cloud storage container.
Step 3: Backup Staging
Zmanda lets you define a scratch disk, which temporarily stores the backups on the server's hard disk. It reduces the time taken for a backup run as multiple backup sets simultaneously load the data to the staging area versus waiting for locks to write directly to the storage container.
In situations where the storage medium is offline/unreachable, backups are stored in the staging area. The data stored in this staging area can also be used for a recovery run if you need to restore a file/directory. Once the error with the storage container is resolved, Zmanda moves the data from the storage media to the final destination in the next backup run.
For the staging area to be used, the backup image should be less than the size of the staging area; otherwise, the backup data is written directly to the storage destination. We recommend the staging area size should be at least the size of one full backup image of all sources in the backup set.
Backup Staging Information
Device name: The storage object which will be used as a staging area. We recommend this be a local disk on the backup server.
Auto Flush: Specifies whether Zmanda should flush the backup images from the staging/area holding disk to the backup media before a backup run. You can monitor flush activity from the ZMC Monitor page. This is useful when your holding space comes at a premium.
Staging Size Limit: It controls the space allocated to the staging medium. Be sure to give enough space to hold at least two full backups.
Reserved for root: To ensure Zmanda doesn't consume all the storage space on the holding disk, you can define hard limits beyond which Zmanda doesn't add data to the holding disk. Backups are paused till space is available in the holding disk, and thus please ensure adequate storage on the holding disk for multiple full backups.
Reserve for Incremental: When space on a staging area falls below a threshold size (the value of this parameter), Zmanda limits itself to performing only incremental backups. A threshold of 20 percent causes Zmanda to fall back to incremental backups when holding disk(s) free space falls below 20 percent.
Backup runs staged at: The absolute path on the staging area where backup images are stored before moving to the final target. The default location is /var/lib/amanda/staging/<backup set name>. The staging area directory must be accessible only by the amandabackup user. The staging area provides better backup performance and an effective media fault tolerance. All backups from the client can be copied to the staging area in parallel. The amount of parallelism depends on the Clients in parallel and other options on the Backup How page.
Step 4: Backup How
It lets you define critical internal parameters that control how the backup set will run after it has been activated. The default values set for these parameters will work well in most situations. Advanced users intending to modify the default values should study the logs and reports of a few past backup runs and, if needed, consult with the support team.
Backup How Information
Media Utilization: This field sets the algorithm that determines the order in which the completed backup images are moved from the staging disk to the backup media. Only completed backups on the holding disk are considered for moving, and the ordering helps better utilize backup media. The options are:
First: (Default value) First in - first out.
First Fit: The first backup image will fit the current media volume.
Largest: The largest backup image first.
Largest Fit: The largest backup image that will fit on the current media volume.
Smallest: The smallest backup image first.
Last: Last in - first out.
Server Parallel Backups: Defines the maximum number of parallel backups that can be run in this backup set. The default value is 10. The server's write speed, network bandwidth, and CPU configurations are essential parameters that define the number of parallel backups.
Client Parallel Backups: Defines the number of parallel backups performed from a single source. The default value is 1, indicating backups on a source happen sequentially.
Media Parallel Backups: Define the number of parallel writes to the storage device.
Backup Order: Whenever two or more data streams must write to the same storage disk simultaneously, there is a conflict on which stream should be allowed to write first. Backup order helps conflict resolution by assigning priorities to each parallel backup data stream.
The possible option choices and their dedication is listed below:
s -> smallest size first
S -> biggest size first
t -> smallest time first
T -> biggest time first
b -> smallest bandwidth first
B -> biggest bandwidth first
An example could be the BTBTBTBTBTBT pattern for scenarios where holding disks have not been assigned a threshold.
Ports for Parallel Backups: The port ranges are used by the Zmanda server to connect to clients. Zmanda will use all the ports in the range that are not bound by another process or not reserved in the /etc/services file. Note that you will have to increase the range (or use a different range) if you increase the server Parallel Backups value.
Notification Type: Defines the type of email notifications that the user would receive.
Email Address: You can enter multiple email addresses separated by a comma, which should be notified on meeting the trigger selected in the Notification Type section.
Backup Estimate: Specify a time out (in seconds) by which each Zmanda client has to respond with a backup size estimate. This limits the amount of time the ZMC will spend on the first planning phase of the backup process. The backup size estimation for all Sources in the backup set is done in parallel. If the time out occurs for a particular Source, then ZMC will not back up that source, and Zmanda will perform a full backup on the source in the next backup run. The time out specified should take into consideration factors such as clients with limited network bandwidth or limited CPU resources.
Verification: The time spent by Zmanda validating if the source is reachable and ready for a backup. The time out applies to all clients in the backup set.
No Data sent: The maximum time the backup server will wait for the source to send the first packet of data. If no data is received in that duration, the backup for that source will be done in the next backup run. The timeout applies to all sources in the backup set.
Step 5: Backup When
In this step, you select the frequency of the backup runs by linking the backup set to the appropriate Schedule plan you created in Step 3. Suppose the schedule plan is set to auto. In that case, the scheduler algorithm on the backup servers helps maintain a consistent backup window across all sources in the backup set by controlling the backup image size for each source. It's enabled by Zmanda, having nine levels of incremental backup.
Backup When Information
Select Schedule: Select the schedule plan you want this backup set to run on.
Step 6: Backup Now
The final screen lets us start the backup run on the backup set. If it's the first time you run the backup set, we recommend triggering an immediate backup using the green play button. The first backup run will take a long time as it must perform full backups of the selected sources, but it lets you diagnose the backup set before activating the backup set to trigger on the scheduled start date.
Backup Now Information
Immediate Backup: Run a quick backup across all sources in the backup set based on the options selected in the radio options below.
Backup Set Activation: It activates the backup set to auto-schedule backups going forward at the scheduled times.
Step 7: Backup Media
Under the manage media, you can specify the backup cycle and retention period in days.
The backup cycle specifies how often Zmanda should run a full backup.
The retention period defines how long a backup should be retained in the storage set, post which ZMC will prune it.
If the storage set is archived, the data from that storage set will not be pruned, even if the data retention period is expired. In the below screenshot, Amazon S3 is being used for archival with forever retention.
Backup Media Tape Handling
ZMC control plane identifies backup media across tapes and vtapes, using labels. Labels ensure that the correct storage tape cassette is loaded in the media changer and that no backup is overwritten before the planned retention cycle is complete. If ZMC finds an unlabelled media, it:
Labels the tape for subsequent identification
It adds this label to its catalog, allowing backups to be written to this media before recycling old cassettes.
When the ZMC finds a cassette belonging to another backup set or media written to by another application, it is not used, and an error message is returned. To manually "force" using a cassette belonging to another backup set, select the Overwrite Media Option described below to Yes.
Backup Media Information
Backup Cycle field (in days): This allows you to specify the number of days between at least one full backup.
Retention field (in days): This allows you to specify the number of days Zmanda will retain the backups.
Prune: Pruning removes all the expired media at once. Unexpired media cannot be pruned.
Recycle: Recycle identifies the media as immediately available for re-use (in other words, existing data on the media will be overwritten and lost). You cannot perform this operation when a backup is in progress.
Archive: Zmanda will take the media volume out of rotation, preventing it from being overwritten once its retention period has expired. ZMC control plane still tracks this media volume and is available for backup restoration.
Verify Integrity icon: Redirects you to the data integrity reports page and generates the corresponding backup report.
Explore icon: Redirects you to the Restore page for the corresponding backup.
Summary
You have successfully configured a regular backup for your sources. If you have any troubles with the configuration, please don't hesitate to contact the Zmanda support teams.
Last updated
