|
Closed
|
Case #
|
10064
|
|
Affiliated Job:
|
New Trier Township District 2031
|
|
|
Opened:
|
Tuesday, April 23, 2013
|
|
Closed:
|
Tuesday, April 23, 2013
|
|
Total Hit Count:
|
29499
|
|
Last Hit:
|
Saturday, December 21, 2024 10:45:34 AM
|
|
Unique Hit Count:
|
8867
|
|
Last Unique Hit:
|
Saturday, December 21, 2024 10:45:34 AM
|
|
Case Type(s):
|
Server
|
|
|
Case Notes(s):
|
All cases are posted for review purposes only. Any implementations should be performed at your own risk.
|
|
|
|
Problem:
|
After an upgrade, performed this summer, to v6.1.0-402, and once we upgraded each of the clients to this latest version of both the Avamar client and SQL agent, any backups performed through Microsoft SQL Management Studio or run manually would interrupt the backup chain and prevent the Avamar backups with Forced Incremental from capturing the transactional logs of databases in Full Recovery mode and thereby preventing the truncation of the transactional log database until a separate, manual non-forced-incremental Avamar full backup was run to start the initial capture and backup of the database.
We discovered, by continuing to use the older v6.0.101-66 Avamar client and SQL agent, we could continue to back up the way we currently do. Our DBA has scheduled daily backups (through a Maintenance Plan) to allow her immediate access to a database without the need to review Avamar and from time to time consultants run backups prior to an upgrade. By using this older agent, we can continue to perform these backups taken outside of Avamar as needed.
However; we have recently discovered a problem with this version of Avamar which from time to time will cause a stripe in the grid to become faulty and require support to repair this stripe and bring the grid back to a consistent state. The only resolution has been to plan a upgrade to the latest SP version of Avamar; however, we are told this new revision will no longer support the v6.0.101-66 Clients/Agents and based on supports original comments, we would have to choose whether backups would be 100% owned by Avamar or 100% owned by SQL with a file agent backup by Avamar.
This to me is ridiculous, the errors in the Avamar log complain about gap detection and snap up errors with regard to those databases in Full Recovery mode when a Avamar backup is taken with Forced Incremental and a manual backup is run in-between. Those exact backups taken using the v6.0.101-66 clients/agents with the in-between "COPY_ONLY" manual backups complete beautifully and when I test out a restore, I can restore to any point in time before, after and in-between any manual backup run using just the before and after v6.0.101-66 backups taken by Avamar. Support; however, continues to claim they repaired problems with prior versions which never observed the SQL log for gaps in the backups and any type of backup run, even COPY_ONLY, will interrupt this chain.
|
|
|
Action(s) Performed:
|
|
Total Action(s): 2
|
|
Action #
|
Recorded Date
|
Type
|
Hit(s)
|
User
|
Expand Details
|
|
10216
|
4/23/2013 12:53:12 PM
|
Server
|
3212
|
contact@danieljchu.com
|
A process you can perform on the SQL server is to query the status of backu More ...
|
|
10215
|
4/23/2013 12:29:18 PM
|
Server
|
3342
|
contact@danieljchu.com
|
v6.0.101-66 Backup and Restore Test Process: & More ...
|
|
|
|
Resolution:
|
After demonstrating proof that I can perform point-in-time restores with the v6.0.101-66 despite the COPY_ONLY backups run in-between (regardless of their "bug"), they finally provided me a hotfix that allows the v6.1.0-402 to have COPY_ONLY backups taken in-between Avamar backups, it therefore captures the transactional log databases and truncates the log database successfully. I have tested it and using a similar restore process I have confirmed I can restore to any point-in-time before, after and in-between any manual COPY_ONLY backup performed. There is a slight difference, backups using the v6.1.x agent seem to require the transactional log restore to be performed twice once on each of the two incremental i-0 files.
This hotfix "46780", I am told, is only available for v6.1.0-402 and will soon be available 4/30/2013 for the SP version we are being asked to upgrade to. It comes as a single avsql.exe [there is only 1 file for both 32-bit & 64-bit systems] which is to replace the existing v6.1.0-402 file located in the Program Files\avs\bin folder. There was another hotfix we tried a while back as part of our troubleshooting - hotfix "45717" which is a completely different and I believe unrelated issue, this hotfix did not resolve our issue.
|
|
|
|
|
|
|
|
