Avamar agent and "cloned" systems

The file you're asking about is the cid.bin file. It's located in the Avamar var directory and it contains the name and create time of the Avamar server as well as the client's unique id.

If you're building a template system, I'd actually recommend activating it and backing it up once, then removing the cid.bin file from the Avamar var directory before preparing it for cloning (sysprep, etc.). If you do this, then retire the client from the Avamar side, you now have populated cache files that cover the OS and applications on all of the clones. Be sure to select the option to retain backups indefinitely when you retire the client.

Ian,

thank you for the reply, a couple of follow up questions:

1) because Avamar Grid is multi-homed, clients will be registering against different names (ie: avamar-admin.company.local and avamar-dmz.company.local), so because of that i probably should not register and run that first backup right ? If the template was created when client was registered to DMZ interface on Avamar and it gets deployed to a system on Admin ..it will not work and will require additional client side modification ?

2) What if i simply install the client in the template and delete cid.bin ? Then when the system gets deployed that file will get re-created with the information of the new host ?

3) I think my Windows guys will be using SCCM to deploy physical servers, it can perform MSI/EXE installation. Does Avamar agent support silent installation ?

Thank you

Ian,

Our backups will be going to DD, sounds like installing the agent and not activating it would work for me. Once operating system is deployed from the template, system admin will activate it against the correct interface on Avamar grid.

I do would like to understand #1 you described above. Why would it matter if the caches are populated on a client that is not registered ( I guess i need to better understand what's in the caches in the first place). I also did not understand why  the initial backup needs to be kept forever, especially in the context of registering a node.

Thank you very much

For Avamar backups using the monolithic caches, each file cache entry has two 20-byte SHA-1 hashes (the "file attribute" hash and the "file content" hash) plus 4 bytes of metadata and each hash cache entry has one 20-byte SHA-1 hash plus 4 bytes of metadata.

If we hash up the file attributes and get a hit on that hash in the file cache, we don't have to actually chunk up the file since we know it hasn't changed since the most recent backup. 90% or more of the performance benefit from Avamar comes from the file cache so having an initial backup of the template already in the cache can be a pretty big performance boost.

So why do we need the backup on the server indefinitely? Well, included in the 4 bytes of metadata for each cache entry is a bitmap that associates each hash entry with the root hash of the 16 most recent backups. If the bit is set for a particular root hash, it means that hash was backed up as part of that backup.

When the client starts a new backup, the first thing it does is query the server to find out if the root hashes of the 16 most recent backups are still present. If these backups are present, it means all the cached information associated with these hashes is valid and the cache information will be used. This cache validation look-up just asks if the root hashes are present -- the client doesn't care what client the backup "belongs" to, only that it's on the system somewhere.

If you back up a client before running sysprep and turning it into a template, every time a new instance of that template is deployed, the initial backup will load the cache, confirm that the root hash for the template backup is present, then use the cache information associated with that backup to avoid having to reprocess all of the OS and application files. If the template backup is allowed to expire, the data will still be on the server but we'll have to chunk up all the files and send every hash to the server because the client has no way to know that the cache data is still valid.

I hope that clarifies things. Feel free to reply if you have additional questions.

very interesting, thank you for taking the time to explain this.  What is "root" hash ?

You're welcome!

As I'm sure you know, a hash in Avamar uniquely identifies some piece of data. The Avamar system builds a Merkle Tree (see Merkle tree - Wikipedia, the free encyclopedia) so there can be hashes of sets of hashes. The hash of a set of hashes uniquely identifies a whole branch of the tree. The root hash is the hash at the top of the tree and it uniquely represents an entire backup.

Because Avamar builds a Merkle tree and runs daily referential integrity checks on the server (so we know that every entry in the tree points to a valid piece of data), we can guarantee that all the child hashes are on the system if a lookup of the root hash succeeds.

Thank you Ian,  root hash of set of hashes ...now we are going deep and over my head

If we're both at EMC World I'll draw you a picture.

it's a deal, adult beverage on me