Define the storage destination for your backups, which can vary from disks, clouds, or tapes.
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 the backup server and backup agent running or are seeking to learn more about storage.
A storage container is bound to a single backup set, ensuring data present in that storage container is exclusively from one backup set. This binding is configured while creating the storage set and can be quickly edited by clicking the configure icon for the respective storage container.
On deleting a storage container from the ZMC control plane, the data present on the disk is not deleted unless manually selected by the user in the delete options. In scenarios where you want multiple storage containers from a single disk, you can create different folders in the disk, where each folder becomes a storage container. This virtual separation of data based on backup sets enables recovery to be managed efficiently.
Simulating the creation of multiple storage sets, from a single disk/cloud storage container
Deciding the storage medium boils down to the data retention period and the cost of storing data. Suppose the backup data is likely to be used in the next 30 days; keeping it on the backup server's disk would be ideal for a quick RTO. Post the 30-day retention period; you could move this data to the cloud to leverage the lower cost per TB on cloud platforms.
Tapes are an ideal storage form when data needs to be retained over decades. Based on your recovery architecture, full backups can be taken on tapes every quarter with incremental backups every week.
Deciding on the storage device, based on retention periods.

Creating a Storage Target

Once you log in to your ZMC control plane, click on the Storage Tab from the side menu. The storage overview screen is loaded, which lists all your storage endpoints. To add a storage medium, click the Add Storage button on the top right, and ZMC will present you with four options: cloud storage, legacy, simple disk, or tape storage. For a detailed setup guide, please see the Storage Configuration page.
Storage Set Process Overview

Storage Information

Different fields will be visible based on your selection among cloud, legacy, simple disk, or tape storage. Once you add a storage medium, Zmanda will attempt to discover the storage medium. If the ZMC cannot detect the storage medium, an error will be displayed in the storage overview section.
Type: Using this dropdown, you define the storage destination of your backup data.
AE Servers: This multi-select dropdown allows you to link this storage set to multiple backup servers. Storage mediums are linked to backup servers so that during a backup, the backup server can transfer data from its holding disk to the target medium.
Name: A unique identifier that is used to identify the storage medium.
Comments: Any descriptive phrases, such as operational notes or storage identifiers.
Cloud Object Size: Size of objects stored in the storage medium. If there is a network transmission failure, the object is re-transmitted. You can use larger cloud object sizes for reliable network connections.
Cloud Object Abbr: It denotes the Cloud Object Size multiplier in bytes. You can select from KB or MB.
Cloud Encrypt: You can encrypt data moving to the cloud with AES256 encryption. The encryption key is stored locally on the Backup Server at /var/lib/amanda/.am_passphrase.
Bucket Names: You can use the DNS or URL path for the storage bucket names.
Reuse Connections: When a cloud communication failure occurs, Zmanda will reuse the existing communication handle instead of recreating a new one. The default is to reuse communication handles.
Secure Communications: Enable this to perform secure SSL transfers of data packets to and from cloud buckets. We recommend enabling secure communications.
Immutable Backup: Enable this to prevent modifying your backup up data on AWS/Wasabi cloud storage. You can learn more about it in the user guide and KB.

Cloud Storage Fields

Storage Options: You can choose between hot and cold storage options, for the cloud provider of your choice. A storage medium that has large data retrieval time is less expensive. If you change this value in the future, the ZMC control plane does not move the data between storage containers.
Cloud URL path field: The URL path that Zmanda should reach to authenticate and transfer backup data. ZMC prefills this data based on the cloud option selected; like in Amazon S3, it will read as
Key access fields: They are a group of fields generated by your cloud provider, enabling the ZMC control plane to authenticate its access to the cloud provider. These fields on the ZMC control plane include Account Key Field, Access Key Field, Secret Key Field, User Token Field, Project Id field, Project Name field, and User Domain field.
Use Untrusted Certificate checkbox: For certain cloud storage options like Openstack, if you choose not to use Trusted Certificate ID, please enable this to prevent errors while connecting with the storage medium.

Legacy fields

Root Path: The absolute path from the backup server, where the backup images are to be stored. By default, ZMC fills in the field with /var/lib/amanda/vtapes/. The zmandabackup user must have permission to write to this directory, and it should be large enough to hold images for all intended backups.
Reserved Percent: Percentage of the file system that should be kept free. This reserved space is based on the recommendation of your storage manufacturer. Once the disk reaches this threshold, the ZMC control plane offers warning messages.
Output Buffer Size, Output Buffer Abbr, and Maximum Total Media: Do not change this value unless the Zmanda support team recommends changing these values for the backup set configuration.
Determine Media Size Automatically Checkbox: This allows you to choose if you want to enable ZMC to autodetect the media size in the tape slot.

Tape Storage fields

Tape Changer: Click this option to list the tape changers detected by the operating system and the ZMC. If you want ZMC to locate a tape change on a custom path, click on custom. For auto-detection to work, you must install the mt-st Linux package on the ZMC server.
Output Buffer Size: This allows you to specify the maximum number of bytes you can send to the storage medium simultaneously.
Output Buffer Abbr: Let you select the multiplier in KBs or MBs for the above Output Buffer Size.
Next Drive Strategy: This allows you to specify how ZMC should choose the next drive for backup storage when multiple drives are available.
Status Poll Interval: Defines the interval time between consecutive MTX status pings.
Unload Delay field: This allows you to specify the delay period after unloading a tape.
Eject Delay field: This allows you to specify the delay period after ejecting a tape before unloading it to the storage slot.
First Poll field: Defines the delay period after loading a new tape before it's polled for status.
Poll Frequency field: Define the poll frequency every minute post-completion of the first poll.
Max wait for Ready field: Allows you to specify the wait time in seconds for the drive to be ready.
Total Slots field: You can manually enter the number of tape slots available.
Bar Code Reader checkbox: Barcodes enable the backup server to load the correct cassette into the tape changer. If you disable the bar code reader, Zmanda has no way of identifying if it's loading the cassette or not.
MT Offline checkbox: A command which is passed by the backup server to the Tape library. Zmanda unloads the tapes using "mt unload" from the tape drives after it finishes writing. So this check box confirms if the tape library requires an "mt offline" command to be run before "mt unload."