7 Valuable VMware Infrastructure Backup Tips
At small companies or in brand-new virtual infrastructures, backup can be straight forward. You may be able to use a free tool that makes VMware backup deceivingly simple.
However, over time, your infrastructure will probably grow, as well as the number of virtual machines and the amount of data needing backup. As this happens, you'll find what other virtualization experts have already figured out - virtualization backup can be much more complex that it seems and you need the right tool for the job.
In this article, you'll learn how to save time, prevent data-loss, and create a bulletproof VMware backup infrastructure by employing the 7 valuable VMware infrastructure backup tips from virtualization backup experts.
Selecting the right tool for the job of backing up your virtual infrastructure is the critical piece of your entire virtual infrastructure protection plan.
1. Here are the steps I recommend to select the right backup tool for your virtual infrastructure:
1. Don't assume you have to select the same tool as everyone else. There are a number of good tools on the market. Just because a tool has the best marketing strategy doesn't make it the best tool. Do your own research and find the best tool for your environment.
2. Test tools for yourself and take your time doing it. Every tool offers a free trial period that allows you to test their product on your own infrastructure (plus, if you are really interested in the product, most companies will give you a free extension to try their product longer than the original trial). Make sure that you test these tools in a test environment and not your live infrastructure. Put these tools through their paces, with your applications, and focus on features related to recovery.
Remember, you aren't just getting a tool to backup your VMs, what you really want is them to be restored and FAST. Test things like multiple restores at a time, file level restore, and application integrity after restore.
3. Make your life easier by selecting a tool that has the latest features. Your tool should offer features like fast restore for multiple VMs, application integrity in your backups, replication, backup of multiple hypervisors, backup of physical and virtual servers, deduplication, and more. Cost make effect your decision here...
2. Avoid VMware Snapshots of Virtual Machines
Snapshots aren't backup. Snapshots should only be used for very short-term and not as your primary backup method. Let's say that you are about to perform an application upgrade, you would take a snapshot (and do a backup) before the upgrade. Then, the next day, if the app upgrade was successful, you would remove your shapshot.
A week later you needed a pre-upgrade database then you could restore if from your backup and not the snapshot.
Snapshots take up tons of disk space and space in your backup repository. Space used by snapshots is, many times, forgotten and easily overlooked, causing unexpected results.
3. Plan for Offsite Backup and Replication
The problem with so many VMWare backup tools is that they stop once something is backed up. They leave the files on a disk and leave it up to you to figure out how to get them offsite in case there is a disaster.
Something else to consider is that you may need to recover a virtual server on a physical server or vice versa. Can your backup product cover all of these scenarios?
I recommend moving to 100% virtualization, backing up all VMs, and then replicating those backups offsite. In the event of a disaster, you'll be able to bring them up at the DR site. And more importantly all your data will be on another site if you just need to restore one VM.
4. Test your backups!
Just because your backup software tells you that backups were "100% successful", doesn't mean that you can restore your data. You need to either manually test your virtual machine restores AND applications inside or have your backup software do this for you.
How many VMs have you restored that bluescreened when they were booted up?
How many VMs have you restored that had corrupted Exchange or SQL server databases?
To ensure that your backups will be 100% recoverable, make sure that you test:
• VM image level restore
• VM file level restore
• The VMs boot successfully and filesystems (like NTFS) mount perfectly
• The application databases mount and services start (e.g. Exchange, SQL, and SharePoint)
Testing all of this on a periodic basis can be very time consuming but it is vital to save your bacon and your job / company should it ever be needed in an emergency.
5. Cloud Backup and DR
Replicating to your own secondary datacenter is an option however not everyone has a secondary datacenter, nor does it make sense for everyone to build one. Cloud-based disaster recovery services are now available that can store your replicated data pretty affordably so worth considering.
6. How Applications Affect Backups
End users now expect applications like Exchange, SQL, and Sharepoint to be available 24 x 7. There is no more backup window. Your backup software must be able to:
• Backup mission critical applications without downtime
• Verify that backups have application integrity
• Restore individual items from mission critical applications back into production
The purpose of your backups is to also protect your applications. Make sure that your backup software not only backs up VMs, but recovers your critical application data.
7. Agent-less vs agent-based backup
From our experience, agents may be a headache to deploy but they do tend to be more reliable communication with the agent and server. However, agent-less backups means it is very simply to deploy and manage. So look at both options and see which one works best for you.
Conclusion
Make sure that you plan for offsite backup and replication, consider cloud-based backup, and use automated testing to ensure backups are recoverable. Selecting a backup tool that knows your applications and can reliably restore them is crucial. Finally, don't dismiss any tool without fully understanding and testing its capabilities, personally in your test environment.
However, over time, your infrastructure will probably grow, as well as the number of virtual machines and the amount of data needing backup. As this happens, you'll find what other virtualization experts have already figured out - virtualization backup can be much more complex that it seems and you need the right tool for the job.
In this article, you'll learn how to save time, prevent data-loss, and create a bulletproof VMware backup infrastructure by employing the 7 valuable VMware infrastructure backup tips from virtualization backup experts.
Selecting the right tool for the job of backing up your virtual infrastructure is the critical piece of your entire virtual infrastructure protection plan.
1. Here are the steps I recommend to select the right backup tool for your virtual infrastructure:
1. Don't assume you have to select the same tool as everyone else. There are a number of good tools on the market. Just because a tool has the best marketing strategy doesn't make it the best tool. Do your own research and find the best tool for your environment.
2. Test tools for yourself and take your time doing it. Every tool offers a free trial period that allows you to test their product on your own infrastructure (plus, if you are really interested in the product, most companies will give you a free extension to try their product longer than the original trial). Make sure that you test these tools in a test environment and not your live infrastructure. Put these tools through their paces, with your applications, and focus on features related to recovery.
Remember, you aren't just getting a tool to backup your VMs, what you really want is them to be restored and FAST. Test things like multiple restores at a time, file level restore, and application integrity after restore.
3. Make your life easier by selecting a tool that has the latest features. Your tool should offer features like fast restore for multiple VMs, application integrity in your backups, replication, backup of multiple hypervisors, backup of physical and virtual servers, deduplication, and more. Cost make effect your decision here...
2. Avoid VMware Snapshots of Virtual Machines
Snapshots aren't backup. Snapshots should only be used for very short-term and not as your primary backup method. Let's say that you are about to perform an application upgrade, you would take a snapshot (and do a backup) before the upgrade. Then, the next day, if the app upgrade was successful, you would remove your shapshot.
A week later you needed a pre-upgrade database then you could restore if from your backup and not the snapshot.
Snapshots take up tons of disk space and space in your backup repository. Space used by snapshots is, many times, forgotten and easily overlooked, causing unexpected results.
3. Plan for Offsite Backup and Replication
The problem with so many VMWare backup tools is that they stop once something is backed up. They leave the files on a disk and leave it up to you to figure out how to get them offsite in case there is a disaster.
Something else to consider is that you may need to recover a virtual server on a physical server or vice versa. Can your backup product cover all of these scenarios?
I recommend moving to 100% virtualization, backing up all VMs, and then replicating those backups offsite. In the event of a disaster, you'll be able to bring them up at the DR site. And more importantly all your data will be on another site if you just need to restore one VM.
4. Test your backups!
Just because your backup software tells you that backups were "100% successful", doesn't mean that you can restore your data. You need to either manually test your virtual machine restores AND applications inside or have your backup software do this for you.
How many VMs have you restored that bluescreened when they were booted up?
How many VMs have you restored that had corrupted Exchange or SQL server databases?
To ensure that your backups will be 100% recoverable, make sure that you test:
• VM image level restore
• VM file level restore
• The VMs boot successfully and filesystems (like NTFS) mount perfectly
• The application databases mount and services start (e.g. Exchange, SQL, and SharePoint)
Testing all of this on a periodic basis can be very time consuming but it is vital to save your bacon and your job / company should it ever be needed in an emergency.
5. Cloud Backup and DR
Replicating to your own secondary datacenter is an option however not everyone has a secondary datacenter, nor does it make sense for everyone to build one. Cloud-based disaster recovery services are now available that can store your replicated data pretty affordably so worth considering.
6. How Applications Affect Backups
End users now expect applications like Exchange, SQL, and Sharepoint to be available 24 x 7. There is no more backup window. Your backup software must be able to:
• Backup mission critical applications without downtime
• Verify that backups have application integrity
• Restore individual items from mission critical applications back into production
The purpose of your backups is to also protect your applications. Make sure that your backup software not only backs up VMs, but recovers your critical application data.
7. Agent-less vs agent-based backup
From our experience, agents may be a headache to deploy but they do tend to be more reliable communication with the agent and server. However, agent-less backups means it is very simply to deploy and manage. So look at both options and see which one works best for you.
Conclusion
Make sure that you plan for offsite backup and replication, consider cloud-based backup, and use automated testing to ensure backups are recoverable. Selecting a backup tool that knows your applications and can reliably restore them is crucial. Finally, don't dismiss any tool without fully understanding and testing its capabilities, personally in your test environment.
Comments
Post a Comment