Avamar RAIN

Avamar supports two basic types of standard Avamar server configurations, which are:

- Non-RAIN and 

- RAIN.

Non-RAIN configurations consist of a single stand-alone node. In single node configurations, both utility and data functions are provided. Non-RAIN configurations require replication. (Previous versions of Avamar supported 1x2 servers consisting of 1 utility and two data nodes).

RAIN configurations include one utility node, three or more data storage nodes, and a spare data node. Currently, the largest standard configuration consists of 16 data nodes, 1 utility node, and 1 spare data node. A minimum RAIN configuration is 1x3 server.

In a multi-node system, the nodes operate together as one server. The hostname and the IP address of the utility node are the identity of the Avamar server for access and client/server communication. Avamar load balances data across all available nodes in a server. With node architecture, Avamar can be easily scaled by adding more nodes.

Avamar Replication

Avamar replication is a feature that transfers data from a “source” Avamar server to a “destination” Avamar server. All data in the destination server can be directly restored back to primary storage without having to be staged through the source Avamar server.

You can use either Avamar Administrator or Avamar Enterprise Manager to manage your replication settings.

Efficient Data Transfers. Replication is accomplished by way of highly efficient, asynchronous Internet Protocol (IP) data transfers, which can be scheduled during off-peak hours to make optimum use of network bandwidth.

Additionally, like other members of the Avamar product family, replication uses sophisticated data de-duplication technology that finds and eliminates redundant sequences of data before it is sent to the destination server, thereby reducing network traffic and promoting efficient use of hard disk storage.

Remote Branch Disaster Recovery. Replication enables the efficient replication of data stored in a single-node server to a multi-node server. Using replication, a distributed enterprise can centrally protect and manage multiple remote branch offices that are using individual single-node servers for local backup and restore. The centralized multi-node server can then be used for disaster recovery, in the event of catastrophic data loss at any remote branch office.

Enterprise Data Center Disaster Recovery. Replication can also be used to replicate data stored in a multi-node server to any other multi-node server in your enterprise. In this manner, multi-node servers can provide peer-to-peer disaster recovery for each other.

Avamar Data Deduplication

Data Deduplication
Avamar differs from traditional backup and restore solutions by identifying and storing only unique, sub-file data objects. Redundant data is identified at the source, drastically reducing the amount of backup data that travels across the network to be stored and managed by the backup host. When storing data objects, Avamar takes maximum advantage of inherent hard-disk characteristics. Avamar also creates and stores “trees” that link all data objects from a single backup. These “trees” are used to re-create files for restore.

Data deduplication, or single instance storage, reduces storage needs by identifying duplicate or redundant data. Only unique data is then stored on the storage media. The level at which data deduplication is employed determines the granularity of deduplication. Three levels of data deduplication are:

File level deduplication helps organizations reduce storage needs for file servers by identifying duplicate files within hard disk volumes and providing an efficient mechanism for consolidating them. The most common implementation of single instance storage is at the file level. With this method, a single change in a file results in the entire file being identified as unique. As shown in the example, if there were 5 versions of a file in a backup environment, the 5 files in their entirety are stored.

Fixed block deduplication, also called fixed length deduplication, is commonly employed in snapshot and replication technologies. This method breaks a file into fixed length sub-objects. However, even with small changes to the data, all fixed length segments in a dataset can change despite the fact that very little of the dataset has actually changed.

Variable block level deduplication uses an intelligent method of determining segment size that looks at the data itself to determine repeatable boundary points. Variable block level deduplication yields a greater granularity in identifying duplicate data, eliminating the inefficiencies of file level and fixed block level deduplication. With variable block level deduplication, a change in a file results in only the variable-sized block containing the change being identified as unique. Consequently, more data is identified as common data, and in the case of backup, there is less data to store as only the unique data is backed up. This is the method used by Avamar.

Avamar Components

In an Avamar system, what makes up the system are the following 3 major components.  They are Avamar server, Avamar backup clients, and Avamar Administrator.

Avamar Server 
- Client backups are stored on this server.  This server provides essential processes and services required for client access and remote system administration. Take note that the following processes: Avamar Administrator Server (mcs) and Avamar Data Server (gsan) run on the Avamar server.

Avamar Client Software
- After software installation on the clients, Avamar client software runs on each computer or network server that is being backed up. This provides client software for various computing platforms. Each client consists of a client agent and one or more plug-ins.

Avamar Administrator Console
- This console software is installed on any supported Windows or client computer. which is able to access the Avamar system on the network.  From then on, this user management console software application is used to remotely administer the Avamar system.

NetApp Qtrees

A NetApp qtree is a directory with special properties.  Originally, the "Q" is the quota and also know as the “quota-tree”.  Quota-tree can be used to set a quota on a particular directory.

Nowadays, we have FlexVols in NetApp, which also can be quota-limited.  In addition to a quota, a qtree possesses a few other properties.

A qtree enables you to apply attributes such as oplocks and security style to a subset of files and directories rather than to an entire volume.
Single files can be moved across a qtree without moving the data blocks. Directories cannot be moved across a qtree. However, since most clients use recursion to move the children of directories, the actual observed behavior is that directories are copied and files are then moved. Security style & oplocks settings can be different than rest of volume.

The following describes the replication relationship to qtress:

SnapMirror 
- Whole volumes OR qtrees can be replicated

SnapVault 
- Only qtrees can be replicated

OSSV (Open Systems SnapVault)
- Only directories can be replicated to qtrees

Find Avamar's Serial Number via SSH

If you are not at the data center location, and you need to access Avamar's hardware serial number per node, the following command line will help you to obtain Avamar's serial number.

1. Login to the Avamar node as root
2. Execute

root@avamarnode:~/#: /usr/bin/ipmitool fru print 0 | grep "Product Asset Tag" | sed "s/^.*: *\(.*\)/\1/"