Metadata for avamar integration w/data domain?

The metadata stored on Avamar for the Data Domain backups will contain the original file name and path, I18N file name and attributes.

Data domain will also store a copy of that metadata in a file called ddr_files.xml

Hello Nr,

Do you know what is the approximate size of metadata for single file stored on DataDomain? I suppose that the size of metadata is the same meaningless of the size of backup file, isn't it?

Thank you in advance!

Kiril Dakov

The size of Metadata per file could vary dramatically in certain cases. Since all of the File attributes including its path, various dates (creation, last access, last write, last backup, etc) size protection information, labels and tags etc. Metadata also contains information such as which backup set it belongs to, where in the Avamar domain it resides, and backup retention information, location in the DD mtree and more.

But the one thing that has the most dramatic affect on the size of a given file's metadata is any ACL (Access Control List) information. Many files do not have any ACLs associated with it but some files can have very large complex ACLs. Certainly the larger the ACL the larger the additional Metadata space that is required.

In general you really do not need to worry about Metadata, Avamar does a very good job of dealing with it. The only time that metadata becomes an issue is if you are taking an existing Avamar Server which has used a fair share of its capacity storing backup data, and you wish to add Data Domain for Data storage and either migrate or add clients to now send backup data to the Data Domain. This becomes a much bigger issue if you are upgrading your Avamar from a 6.x version to a 7.x version.

In either case the old existing stripes (containers for deduped information) that held the old data cannot be removed or re-purposed for the storage of Metadata even if they are completely empty. This is why deleting backups does nothing to help remediate a metadata problem. It is even worse if you move backup sets from Avamar ADS storage to data domain. This is because the data can exist on both the Data Domain and in the Avamar GSAN, and the Metadata for the backup sets would be recorded twice in the Avamar GSAN, once for the Avamar data and again for the Data Domain version of that same data. This problem is reduced as the old data on the Avamar GSAN expires and is cleaned up by the Garbage Collection, but only reduced, not removed.

If you are considering migrating towards a combined solution of Avamar and Data Domain (which can be very cost effective) the best course of action is to start fresh with a new Single Node Avamar, with Data Domain already configured, then Migrate clients off of the old Avamar ADS or AVE server, on to the new Integrated Avamar/Data Domain solution.

If you go this route, I cant tell you how much capacity you can get, but it is mainly limited by your Data Domain capacity and not so much by the Avamar Single node's metadata capacity. We have had many customers migrate their large 1x16 Avamar Grids to a Single node & Data Domain solution.

Remember it is better to start fresh and new with an Avamar/Data Domain solution rather than re-purpose an existing Avamar Server that has used a fair share or most of its capacity.