Sources
Using source, you define what to back up. A source could range from workloads, directories, or applications you want to back up and can be linked to multiple backup sets.
Last updated
Was this helpful?
Zmanda Classic
Using source, you define what to back up. A source could range from workloads, directories, or applications you want to back up and can be linked to multiple backup sets.
Last updated
Was this helpful?
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 sources.
Using source, you define which define workloads, directories, or applications you want to back up. The source should be reachable from the backup server. In most production scenarios, we notice backup plans requiring data from a source to be stored on disk and cloud to offer data redundancy in case of a disaster. To build this configuration, you link one source to multiple backup sets.
Once you log in to your ZMC control plane, click on the Sources Tab in the side menu. It takes you to the sources screen, listing all created sources. To add a source, click the Add Source button on the top right, and ZMC will present you with four options: File Systems, Databases, Applications, and HyperVisor.
Based on your selection above, different fields will be visible. On successfully creating a source, ZMC will ping the host to check its discoverability. The result of the host check will be available on the sources overview.
Type: Identifies the type of source you want to backup. Using the available options, you can choose among file systems, databases, hypervisors, or applications.
Hostname: The IP address of the source/client you want to backup in x.x.x.x format.
Directory Path: The absolute path of the source directory or file you want to backup. Unless exclusions are specified, files inside a directory are recursively added to the scope of the backup.
Data Deduplication: We support file and block level data deduplication. When enabled, Zmanda intelligently optimizes your storage at a file level using file metadata or at a block level by recognizing duplicate byte patterns. Thus, you cannot encrypt or compress your data when deduplication is active.
Encryption strategy: Protect your sensitive data at rest by encrypting it at the server or the client. Your encryption keys are stored at /var/lib/amanda/.am_passphrase. Please keep the encryption key safe, as Zmanda doesn't maintain a backup of your keys, ensuring only you can access your encrypted data.
Compression Strategy: Allows you to compress the backup data before being stored on a storage medium. Higher compression would result in slower backup runs but will occupy a smaller size. Below are the compression options.
Fast: Quick backup runs, often with larger file sizes due to low compression rate.
Best: Offers the best compression possible but leads to higher CPU usage and long backup windows.
Custom: It uses the Pigz compression technique. On selecting Custom, you should specify the path to the Pigz file on the client/server.
Exclude Paths: Select which file you don't want to back up. File/folders added here are also excluded from the encryption and compression runs, allowing you to optimize CPU resources.
Comments: You can add any operational or performance notes here for future reference. To read your comments, please enter the edit mode for the source.
Backup Estimates: Limits the amount of time the ZMC will spend on the planning phase of the backup process. Every Zmanda client determines the change in data and what is the total size of that change. The estimation phase may take hours if there are many clients or if the clients have a large amount of data. After computing the size estimates, Zmanda develops a backup plan for all clients and begins the backup.
Backup Strategy: Define the conditions when ZMC must take a full or incremental backup. Unless instructed by the support team, we recommend keeping this on default.
Backup Staging: Defines if the backed-up data should flow through staging. If set to required, backups happen irrespective of the status of the target medium. If set to false, backup runs are executed only if the target medium is ready. Please ensure there is enough storage space on the staging disk for one complete source backup.
Extended Attributes: It changes the packaging method to sTar to allow backups of extended file attributes.
Backup Sets: Given that one source can be mapped to multiple backup sets, you can map multiple backup sets to this source using this field.
Tags: Custom user-created tags; allow you to create a virtual grouping among your sources. Helpful to group sources when you have hundreds of sources under backup.
ZMC Template: This allows you to enter the name of the windows template you created in the Zmanda Windows Client configuration utility.
All Local Drives: It's a template that will backup all the local drives on your windows machine, eg: C:\, D:\, E:\, etc.
Volume Name: Name of the NDMP volume
Vendor: Indicates the NDMP appliance type. It can be Netapp, BlueArc, EMC Celera , or Sun Unified Storage.
Mounted Directory: Absolute path name of the file system you mounted on your backup server.
Share Name: Share name represented in UNC format (ie → \\CIFSserver\share\sub-directory). The below architecture shows the mapping of drives in CIFS configuration.
