Veeam has been a part of my technology landscape ever since releasing version 4 back in 2009. At that time, the company was rather refreshing in their focus on backing up virtual machines as an entity, rather than something to shove a guest agent into, which was a new enough concept for the time. I’ve enjoyed working with their team to provide feedback (because they actually listen) and applaud their efforts to provide free NFR licensing to a vast number of technologists in several communities.
I’ve taken the time to upgrade my lab installation of Veeam from version 6.5 to version 7 and outline the steps taken here, along with some impressions on two new key features.
Upgrade Preparation
I find it important to complete a few preparation steps before diving right into any upgrade. Namely:
- Read the version 7 release notes and any upgrade documentation – Check the known issues to avoid them, and understand fully what will occur when you perform the upgrade.
- Take a full backup of your database
- Take a full backup of the Veeam server(s) or use a VMware snapshot on a virtual machine.
I have daily full backups of all my SQL databases, making that step a non issue. I did end up powering off the Veeam server, taking a snapshot, and powering it back on. This serves two purposes: I know I have a rollback plan and I just verified that the server is healthy enough to survive a reboot. You’d be amazed at how long a system partition can be corrupted without notice (until someone reboots the server).
The Upgrade Process
Upon inserting the Veeam ISO file, which is the new install format with version 7, into my virtual machine and running setup I was greeted by this friendly installation screen. It kind of reminds me of the new Windows 8 style of art used with the Start tiles. I clicked the Veeam Backup and Replication “upgrade” button.
The upgrade installer asked me to accept the EULA and other standard questions. Then a list of the products and versions installed appeared, which verified the software installed on the server.
The next step prompted for a license file.
The Veeam installer completed a system configuration check to ensure I had the supplemental packages installed. If any did not pass the test, I would have needed to resolve the item and re-run the check. I was lucky enough to pass all the tests on the first try. 🙂
I then provided a service account that has full dbo (database owner) rights on the Veeam database, along with Full Control authority on the catalog folder. I like to use a specific service account, which is a user named “svc_veeam” for all Veeam services.
The next screen wanted information on my SQL database. In my case it was automatically populated with the correct information, but it can be edited if necessary. Once I clicked Next, a nag screen appeared warning me that the database will be upgraded to the new version (make sure you have a backup!).
I clicked Install and basked in the warm glow of a progress bar. My upgrade took about 5 minutes. Time to fire up version 7!
My next tasks are to test a few of the enhancements listed for version 7: Parallel Processing and Transparent backup of the vCenter Server VM.
Parallel Processing for Backup Jobs
The first new feature I tested was parallel processing. This allows the backup job to process multiple virtual disks and virtual machines in parallel. Sounds neat, right? There’s a fair bit of “dead time” in a backup where the system is waiting on vCenter to perform certain tasks, so this feature should eat up a lot of that time.
The feature is NOT enabled by default after the upgrade, so you’ll have to turn it on by navigating to Options > Advanced > Parallel Processing > Enable check box.
Note for users upgrading to v7: By default, all behavior-modifying engine enhancements, such as parallel processing, Backup from Storage Snapshots and the new default compression level, are not enabled upon upgrade. This ensures your existing jobs do not change behavior when you upgrade to v7. (source)
To verify the value of this feature, I ran the following tests to try and see how much time savings I could gleam when the data set were not an issue:
- Active Full backup job on 11 VMs in my lab. This ensures I have all the data prior to speed testing.
- Regular synthetic of the same backup job with parallel processing disabled
- Regular synthetic of the same backup job with parallel processing enabled
Test Results
- Duration: 29 min 26 sec
- Rate: 55 MB/s
- Processed: 120.1 GB
- Read: 874.0 MB
- Transferred: 232.9 MB
Parallel Processing Enabled
- Duration: 15 min 59 sec (46% faster)
- Rate: 57 MB/s
- Processed: 120.1 GB
- Read: 1.2 GB
- Transferred: 353.9 MB
Transparent backup of vCenter Server
In order to back up the vCenter Server VM in Veeam version 6.5, I had to create a job that specifically connects to the host that vCenter is on and back it up directly (as per KB1051) . Otherwise there is a moment where vCenter is non responsive and the backup server fails the job because a snapshot would never occur. This is supposedly fixed in version 7, so let’s put it to the test!
To begin, I created a new job that tries to backup the vCenter Server VM via vCenter. I then kicked off the backup job twice and noticed that it completed successfully both times. Awesome!
And here’s a view from the vSphere Client showing the successful creation and removal of both sets of backup snapshots.
Thoughts
I’m only scratching the surface of all the new improvements, but must confess that I use very little of the advanced features in my lab on a day-to-day basis. The upgrade process was very simple and painless, and I noticed that all of my jobs continued to work as expected even after the upgrade. From an operational standpoint, I’ve noticed quite a few new ways that Veeam version 7 displays data that makes life easier (such as the lower pane of details on a backup job). Backups complete even faster than in version 6.5, especially when parallel processing is enabled, which is something that can help drive down backup window times or increase the volume of VMs that can be backed up.
One thing that sucks is not being able to use the Enterprise Manager to control your Veeam from another machine since it requires the “Enterprise” license. Be nice to be able to access it from any machine.
I’ve been on a Unitrends kick as of late. Have you ever used their setup? They now allow you to backup VM’s in the free ESXi with their “free” version. Plus, you can backup physical and virtual.
Hi Chris, that is not correct. Enterprise Manager does not requires the “Enterprise” license, it is (and has always been) a feature of “Standard” edition.
Veeam provided backup for free backup for ESXi a few years ago (in 2009), but we had to drop this functionality upon VMware request.
Also, how do you normally do your Veeam backups. From what I read, it is best practice to do Active Full’s only once a month.
Also, I use Reversed Incremental since the usually dump spot for the backups doesn’t do deduplication and when reading what’s listed under Incremental it states “Recommended for backup to tape, remote site and deduplicating storage appliances”. I might switch it because I moved it to a Server 2012 CIFS share and I believe 2012 can do deduplication.
Best practice is a slippery slope – adapt the backup policy to meet your workload needs. For me, daily incremental with a weekly synthetic full to an iSCSI mounted drive on my NAS does the trick. The backups are then replicated to an external drive to protect against NAS failure.
We run VMWare 5.x with back end storage being NFS datastores. We are having issues with the VM’s freezing for too long during the snapshot commit process. I’ve tried leveraging both vStorage API and network backups but VM’s seem to freeze for a long period of time using either method. This is causing issues with web servers loosing connectivity to the backend MS SQL DB.
Chatty DBs with a high volume of IO are difficult to quiesce within the hold time. You might try the Veeam forums to see if others have had success with your workload, or go with a SQL specific product such as Red Gate or a SQL maintenance plan.
How long do your VMs “freeze” during the snapshot commit process? Some of our VMs freeze for up to a minute? I know it is kind of a general question and the answer is “it depends”…but I’m thinking this could be an issue with my deployment of VMWare.
Typically less than 10 seconds. I have not traditionally used VADP for my large DBs, as they are protected by the SQL DBAs using other methods already (commonly Red Gate or AAGs). I often just capture the system elements minus the database mount points, but that’s just my world – I’m sure others do it differently 🙂
Thanks!