|
Closed
|
Case #
|
10048
|
|
Affiliated Job:
|
New Trier Township District 2031
|
|
|
Opened:
|
Tuesday, February 1, 2011
|
|
Closed:
|
Monday, February 28, 2011
|
|
Total Hit Count:
|
51086
|
|
Last Hit:
|
Tuesday, April 23, 2024 11:43:19 PM
|
|
Unique Hit Count:
|
11018
|
|
Last Unique Hit:
|
Tuesday, April 23, 2024 11:43:19 PM
|
|
Case Type(s):
|
Server, Vendor Support
|
|
|
Case Notes(s):
|
All cases are posted for review purposes only. Any implementations should be performed at your own risk.
|
|
|
|
Project:
|
After discussion of the future of our backup strategy utilizing Backup Exec; we finally decided to move forward with an EMC Avamar solution. EMC performed an assessment of our network and determined we would be best fit with an Avamar "DS7" grid consisting of a Utility node, Spare node and 5 Data nodes. Under a new platform of Avamar v5.0, each data node includes 3.3 TBs of available storage space.
Since we have nearly virtualized our entire server environment in our array of 5 host servers running the latest and greatest ESX 4.1 vSphere (which we have since learned of EMCs plans to do away with ESX and shift to ESXi for version 5) along with the storage of our infrastructure on an EMC CX-120 - we are good to move forward with a storage based backup solution.
We hired the help of a certified partner of EMC to perform the major install; however, the partner consulting company encountered a great number of difficulties with the hardware provisioned and after a week of troubleshooting, ended up replacing two nodes along with deploying EMC teches to return the grid to a fresh from scratch state.
Therefore, in our planned week worth of time we were only provisioned two actual days, "Day 1" for install and "Day 2" to briefly go over the high level details & job configuration. So below are lessons learned through work I have had to perform to troubleshoot and self-educate various implementations either left uncompleted or missed during the "install."
The consultant performed the install on the nodes individually, then through the "wizard" brought the grid online into a collective state; set the Avamar utility node to trust the root certificate of the vCenter server, setup the initial Avamar proxy (which captures the image level backups of a virtualized machine); imported the VM server environment into Avamar; created the requested datasets, schedules, retention policies; explained the various agents to be installed for File based (rather than image based backups which permits file exclusions, restore permissions with files etc.), SQL, Exchange; LDAP authentication into our A.D. infrastructure and SMTP notifications of "Call Home" to EMC as well as sending us server notifications.
What the consultant failed to explain or setup were a couple items we then figured out on our own. When he finished (on "Day 2") we began an "On Demand" on a couple backups to begin while keeping all others in a disabled state. And before the consultant left we had arranged a return date for him to explain the "how to" restore, review the backed up jobs (success/failure), Avamar reporting, change root/admin passwords, shutting down the grid, backing up of external NAS resources, setup of additional Avamar proxy servers (each proxy performs a single thread - to enhance backup time EMC suggests a proxy per VM host), review of the "System State" File Agent backups on Windows 2003 (Which we discovered were NTBACKUP bkf files being placed on the C volume and in some cases were consuming what little space was left)
To address the above, a great majority had to be performed on our own - simply because our consultant had already spent the 5 days budgeted on our contract building the original units only to find the failed hardware components and therefore had to spend an additional two days to reconfigure the two new nodes with the original 5 other nodes all of which were returned to factory settings after repair. Because of this, the consultant neglected to return on the date arranged and instead the questions were briefly explained through email rather than demonstrated.
|
|
|
Action(s) Performed:
|
|
Total Action(s): 4
|
|
Action #
|
Recorded Date
|
Type
|
Hit(s)
|
User
|
Expand Details
|
|
10165
|
2/28/2011 2:37:07 PM
|
Server
|
3786
|
contact@danieljchu.com
|
Image Level File Level Restores
Some of the lessons learned, most i Collapse ...
|
Last Hit: Tuesday, April 23, 2024 11:41:54 PM
Image Level File Level Restores
Some of the lessons learned, most importantly for me was how to restore data - from the File, SQL and Exchange agent point of view I believe these are fairly simple as they share many similarities to how Backup Exec functioned; the image based backups are a different story. The way our consultant had configured this would be for us to restore the entire VM Image as a new machine, boot it up and pull out of it what files we needed - this was not how EMC explained to us this type of restore could be performed. During our evaluation, there was mention of the ability to go into an image and pull out data as needed by using another type of proxy [a restore proxy], when retrieving files out of an image, the file level NTFS permissions would not be retained; however, for those servers requiring this level of detail we have the file agent backups and these NTFS permissions are of course retained if you restore the image as a whole. When requesting this functionality to our consultant, he confessed he had not performed this before and explained this was not best practice; however, after talking with EMC it is. So the consultant provided the documentation to us and we simply set this up on our own.
This level of restore is not all that complicated - there are two documents which help explain the "How To" setup of this form of restore. It will require a couple things, a Windows server based VM souly used as a Avamar restore proxy (by also installing an Avamar agent onto the server), the AvFS (Avamar File System) & Samba SMB services activated on the utility node, configuration of some files on the grid and finally under the Administration section of the Avamar client, "Edit" the newly added Avamar restore proxy and check each of the "vSphere datastores to protect" in the list provided.
The two documents are:
These document well what to do to get this form a restore up and running. I had a great deal of difficulty finding the 2nd document which is referenced by the first document - our consultant provided this to me and it documents well how to configure the AvFS service. I applied these instructions on our v5.0 Avamar Multi-Unit grid, please do so at your own risk; however, some additional things I leaned about how it works is interesting:
| - | Open to the Backup/Restore window in the Avamar client | | - | Click the "Select for Restore" tab and browse to an image level backup job | | - | Select the "Browse Virtual Disk" icon which then displays in the restore tab each drive in the VM image allowing you to pick what to pull out of the image level backup | | | | o | This process actually re-hydrates the image on the Windows VM acting as the restore proxy in it's Temp folder, what is interesting about this - while you are browsing on the Avamar client what files to restore, you could actually just RDP to the Windows Restore proxy and proceed to the C:\Temp\[UUID]\C\... and grab the files there. I have a screen capture below to demonstrate this. |
|
|
|
|
10166
|
2/28/2011 2:36:07 PM
|
Server
|
3459
|
contact@danieljchu.com
|
Add Additional Avamar Image Backup Proxies
The creation of addition More ...
|
|
10168
|
2/28/2011 2:35:07 PM
|
Server
|
3280
|
contact@danieljchu.com
|
Image Level Backup Failures
Image level backups on VMs that have a More ...
|
|
10167
|
2/28/2011 2:34:07 PM
|
Server
|
3573
|
contact@danieljchu.com
|
Backup Performance
A couple things to mention, when performing back More ...
|
|
|
|
|
|
|
|
|
