2018-11-01 16:00:11 avtar Info <5550>: Successfully logged into Avamar Server [18.1.0-33] (Compression enabled)\n2018-11-01 16:00:11 avtar Info <7563>: Back up of \"\/\" on server \"kronos.turbamentis.int\" for \/clients\/test01.turbamentis.int<\/pre>\nLooking through the log, it identified one gotcha in my lab setup \u2013 I’d forgotten to lock down the Avamar server to only backing up to Data Domain. That’s something that’s done by default when working through an Avamar implementation (and why I don’t do implementations!) Why I know that is when you’re backing up a Data Domain, you’ll see information logged about the Client<>DD connection, such as:<\/p>\n
2018-11-01 19:04:50 avtar Info <40062>: GSAN connected via: IPv4, retrieved Data Domain IPv4 hostname = singularity.turbamentis.int\n2018-11-01 19:04:50 avtar Info <10539>: Connecting to Data Domain Server \"singularity.turbamentis.int\"(1) (LSU: avamar-1516143927) with auth token\n2018-11-01 19:04:50 avtar Info <10540>: - Resolved Data Domain Server name \"singularity.turbamentis.int\" to the IP address \"192.168.100.249\"\n2018-11-01 19:04:50 avtar Info <41236>: - Connecting to Data Domain Server name \"singularity.turbamentis.int\" with token:094e4343d013a88d69bb6ed25230d3e9375d4674<\/pre>\n(That logging, clearly, comes from a new backup I’d executed after correcting my error.)<\/p>\n
After that, the Avamar log reports the file and hash cache files being opened:<\/p>\n
2018-11-01 16:00:11 avtar Info <5586>: Loading cache files from \/usr\/local\/avamar\/var\n2018-11-01 16:00:11 avtar Info <8650>: Opening filename cache file '\/usr\/local\/avamar\/var\/f_cache.dat'\n2018-11-01 16:00:11 avtar Info <5573>: - Loaded filename cache file (92,275,232 bytes), the value maybe the same as previous backups.\n2018-11-01 16:00:11 avtar Info <8650>: Opening hash cache file '\/usr\/local\/avamar\/var\/p_cache.dat'\n2018-11-01 16:00:11 avtar Info <5573>: - Loaded hash cache file (100,663,840 bytes), the value maybethe same as previous backups.\n2018-11-01 16:00:12 avtar Info <6426>: Done loading cache files<\/pre>\nWhen the backup completes you’ll see a wrap-up message:<\/p>\n
2018-11-01 16:05:41 avtar Info <5163>: Backup complete, wrapping-up session with Server<\/pre>\nJust a little above the wrap up message, you’ll see a line that tells you the percentage change encountered between this backup and the last:<\/p>\n
2018-11-01 16:05:41 avtar Info <5156>: Backup #9 timestamp 2018-11-01 16:05:31, 964,577 files, 29,940 directories, 24.17 GB (28 files, 157.4 KB, 0.00% new)<\/pre>\nIn this case, because the test system was pretty much inactive between backups, there was only a tiny about of new content \u2013 enough for Avamar to round it to effectively 0.00%, which makes sense when only 157.4KB had changed on a 24.17GB backup. Here’s an example of output where more new files were discovered, after I generated some new random content on the system:<\/p>\n
2018-11-01 19:32:51 avtar Info <5156>: Backup #11 timestamp 2018-11-01 19:32:40, 1,038,297 files, 32,514 directories, 25.25 GB (67,776 files, 995.9 MB, 3.85% new)<\/pre>\n(In that case, there was almost 1GB of new data, representing about a 3.85% change from the previous backup.)<\/p>\n
Now, after the wrap-up message I’d previously mentioned, you’ll see information logged giving you the other key statistics of the backup \u2013 such as:<\/p>\n
2018-11-01 16:05:41 avtar Info <6083>: Backed-up 24.17 GB in 5.52 minutes: 263 GB\/hour (10,487,183 files\/hour)<\/pre>\nOverall, those are pretty good statistics of course, telling you deduplication is well and truly happening: 24.17 GB backed up in under 6 minutes, a speed of 263 GB per hour, with a file processing equivalent of almost 10.5 million files per hour.<\/p>\n
As you can see, there’s a lot of information you can pull out of an Avamar client log, and it’s always worth while keeping those files in mind as part of operational or fault analysis.<\/p>\n","protected":false},"excerpt":{"rendered":"
If you’re new to Avamar, you might not know that the Avamar backup agent writes a lot of useful information…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[1154,6],"tags":[1486,550],"class_list":["post-7225","post","type-post","status-publish","format-standard","hentry","category-avamar-2","category-basics","tag-avtar","tag-logs"],"aioseo_notices":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pKpIN-1Sx","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/7225","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/comments?post=7225"}],"version-history":[{"count":4,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/7225\/revisions"}],"predecessor-version":[{"id":7333,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/7225\/revisions\/7333"}],"wp:attachment":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/media?parent=7225"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/categories?post=7225"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/tags?post=7225"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"Log](\"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2018\/11\/Log-Analysis.jpg\")
<\/a>On a default install on Linux, you’ll find the logs written into \/usr\/local\/avamar\/var\/clientlogs<\/strong>. (It’ll be a similar scenario for an NDMP accelerator, as well. On Windows for a default install, check out C:\\Program Files\\avs\\var\\clientlogs<\/strong>). Looking in that directory, you’ll find a number of files \u2013 on the test01 server I setup in an earlier blog post<\/a><\/strong>, a directory listing looks like:<\/p>\n