Windows System State Backups with Actifio

Say Whaaaaa ? Yes you heard correctly. Due to numerous customer requests I researched this capability, while it’s not efficient entirely if you include it as part of a daily backup, but we can do it. Read on if you want more. I said it’s not efficient, as the process is essentially creating a new compressed file everyday (10GB+ is not uncommon). What this will do is cause a lot of new unique data to enter into the dedup pool. But here is the thing, we have a few ways to provide the capability without the storage consumption penalty. I will continue to research further to see if we can reduce the file size somehow with Microsoft, but here is what’s possible today. This procedure should work for Windows Server 2008+ and is fairly simple. 1. Local command line backup facilities must be enabled. If they are not these can be added via the GUI, or else run in an administrator command prompt the following command: C:\Windows\>servermanagercmd -install Backup-Tools 2. Run a pre script via VMware Tools, or the Actifio Connector script, with the command in it. wbadmin start -systemstate -backuptarget:D:\ -quiet In the above example the D:\ must exist as a target, but this could easily be changed for the Actifio Staging disk (or mount point) as the target. In future, I hope to further refine the testing to only include the last 1-3 days of data in the local system for recovery and 2, exclude the backup of all files in the C:\Windows\ folder and items beneath it. I would strongly suggest customers don’t do this on every server, and run it daily, but it might form as an additional policy to be run weekly on a domain controller (PDCe) as an example if required on a regular basis. Actifio also supports Bare Metal Recovery, which includes System State Backups as part of the licensing. So this article itself is not part of that solution, as it is built in. Now another approach to solving the idea, without storage penalty you could do the following and it applies only for Virtual Machines. 1. Ensure the machine that you want a system state backup for, has an SLA policy applied that includes the snapshot option. While this is not strictly mandatory, it will help with the speed of recovery for any system state image, as the machine can be mounted back instantly. 2. When you need a system state item, you can do an instant mount of the VM from the point in time you need to recover from. Mount the VM back to a hypervisor and as usual the VM will not be attached to the network. 3. Power on the VM and connect to the console session. Then login using local admin or cached credentials. 4. Run the command as above: wbadmin start -systemstate -backuptarget:D:\ -quiet This will create a system state backup from the VM at the time the snapshot backup was initiated. 5. Then Power down the Virtual Machine. 6. Attach the D:\ VM Disk (or disk where you stored the system state backup image) to any other running VM, normally best to attach to the same VM as where the backup was done, and attach the drive to the running VM. 7. You can then proceed with the System State restore process that you would normally follow, as documented by a Microsoft KB article or TechNet article. 8. Once completed you can Unmount and delete the volume from the running VM, and as a best practise it’s probably wise to initiate a manual backup of the VM/server where the recovery was performed. The benefit to the VM Instant mount approach, is that you still have access to the data, even though it’s not explicitly stored in the dedup pool as a new unique blocks every day. This will save storage in your long term retention pool, and only add an additional few steps in the recovery of system state restores. The instant mount feature Actifio provides greatly reduces the time to recover system state data, along with any files, databases, VM Disks, or entire VMs in seconds. Click to share article:ShareLinkedInTwitter

TripRaider

Working for a Start-Up, we try to save money where we can, and spend it where it will most make sense. As part of this effort across my team, we often need to travel at the last minute to visit with a customer. Sometimes we can plan ahead of time to get good hotel and flight discounts, and other’s we are just unfortunate. So we often will use Wotif or LastMinute.Com to get their secret last minute hotel deals. So I came across this website, that shows you the last minute description of a hotel, and uncovers the real name of the hotel for you. This is especially helpful when you want to ensure you stay close to a customer office, or want to stay at a particular hotel. The site is called:┬áTripRaider And my last helpful tip: I tried to register for the site to add a hotel I stayed at recently in Canberra. A brand new hotel there is called “Hotel Hotel” the secret text for that one is “5* luxury wonder in the heart of Canberra!”┬áThis is a brand new hotel in the recently built Nishi building in Canberra. I recommend the hotel, it’s a funky new style of hotel, and for the last minute price, was money well spent considering some of the hotels I have stayed at in Canberra in my time charging a lot more ! Click to share article:ShareLinkedInTwitter

vCenter authentication fails, even though you know you have the right password!

At one of my customer accounts we were experiencing an issue in one of the customer’s sites. Here is the scenario of the problem. 1. We Tested Authentication with the AD service account setup for Actifio. Authentication failed, even though we knew we had the right login & details. We also ensured we were using the correct syntax DOMAIN\Username to login. 2. Login to the remote vCenter from customers Desktop (which points to a site domain controller in the local site) as the Actifio AD service account. Authentication Works fine, and vCenter is opened and objects displayed. 3. Test creating a snapshot and creating a new VM from vCenter. All works ! 4. Test Authentication in Actifio with the AD service account. Auth failed again. But why ? We know we have the correct details, and it can login via vCenter using the same API calls Actifio would make to login. So, my process of elimination begins. Can we remove the Active Directory as the problem somehow ? Yes, vCenter 5.x and above uses a Single Signon (SSO) process, which can have local accounts. So here is what we tried: 1. Change the service account in actifio, from the AD service account to be the “[email protected]” SSO account (vCenter 5.0 U1), and enter the correct password. Auth Works ! 2. Snapshots work in Actifio, and all is working. Happy Days. So what does this tell us the root cause is ? My thoughts are it’s one of the following. a) Possibly time sync is out between the customers remote site vCenter and the remote site Domain controller. b) The customers remote site Domain Controller is out of sync or not correctly working anymore with Active Directory in the local site. c) The SSO configuration for VMware and allowing authentication against the customers domain is not setup correctly. I am leaning towards (c) as the primary candidate for the problem, with potentially (a) too (as we had seen this another time at the customer site). Either way, this issue is not caused by Actifio or a result of bad code, but it affects us. So knowing how to troubleshoot SSO vCenter authentication is important with the way we authenticate against vCenter in 5.x and above. Hopefully this saves some time for others to help pin-point the potential issue. The key point is remove AD out of the equation, use the SSO admin account, and see if authentication is still not working. Once the root cause of the AD auth issue in the remote site is debugged, we can then go back to using the limited rights AD service account. Click to share article:ShareLinkedInTwitter