If there is anything that has been talked about more, it is Virtualization (and VMWare). In this post, let us examine the pain points for Storage/Backup Admins as to how this is impacting them and IT Backup Infrastructure.
Backups for most VMWare implementations are done via host i.e install a backup agent on the VM and back it up like a regular host. The advantages here are same as you get in a physical host i.e host level recovery. The main disadvantage to this approach is to have a license for each client, in which case your ROI is not any better (for backups). A slightly better approach for this is to backup via ESX server i.e backup agent is installed on ESX and it backs up all the VMDK files. The disadvantage to this is you will be backing up all data regardless of the backup-type (full or incremental). Since vmdk files get modified while VMs are active, an incremental backup is the same size as full. In some cases backups are done at the storage level i.e backup the underlying storage volume via NDMP. This has the same disadvantage as earlier, incremental backup size being same as full. The 'esx way' to do backups, is VCB - in which case, you have to write scripts and have a dedicated server to act as VCB backup server. The main advantage to this being incrementals are really incrementals.
Is it required to go through the pain of setting up VCB backups (maybe that is the reason most of VMWare backups are not done this way)? A recent approach to handle this trouble is to implement 3rd party software to do backups at block level incremental which really seem to be saving lots of trouble and backup size. But wait, if it is that simple why isn't everyone implementing it? Maybe there is a downside to it? Well, what is not advertised with these products is that they add a very-high amount of load on your primary storage thereby making all the VMs suffer from disk resources and everyone ultimately blaming the storage admin for poor disk response and the architect for designing such a poor storage solution. These backup products claim to do a block-level de-duped incremental - which is true, but at the cost of having all the VMs suffer until that backup completes. The product does not have a true deduplicated repository and hence keeps scanning all the blocks in the VMDK (even empty blocks) for any changes. For example, if you have 500g of VMDK but using only 200g and the remaining is white space, all of 500g is now scanned for changed blocks - not once, but everytime a backup is done.
Due diligence need to be done before you choose whichever method you want to implement and make sure the storage guys are involved. This is not just a VMWare admin decision as it impacts other components and ultimately be the storage engineer resposibility to "fix" the problem. You might like the "deduped, block level backups" but you also need to understand what problems it might cause and how to tackle them.
If only there is a real product that can integrate into both ESX and Storage and can do "real" block level incremental with dedupe, that would be a great one. Since it involves storage, I would assume such a product to be coming from a storage vendor since they have insight into the workings of storage - both blocks and dedupe. The initial investment might be high, but you will be happy that you made it, especially with large VMWare deployments.
vSphere is coming out with a vmware-backup methodology that will help from a backup point as well some-kind of DR. They are not trying to make it a full-blown backup product for VMWare (at least not at this time), but if it matures into that, it would be a real help.
Backups for most VMWare implementations are done via host i.e install a backup agent on the VM and back it up like a regular host. The advantages here are same as you get in a physical host i.e host level recovery. The main disadvantage to this approach is to have a license for each client, in which case your ROI is not any better (for backups). A slightly better approach for this is to backup via ESX server i.e backup agent is installed on ESX and it backs up all the VMDK files. The disadvantage to this is you will be backing up all data regardless of the backup-type (full or incremental). Since vmdk files get modified while VMs are active, an incremental backup is the same size as full. In some cases backups are done at the storage level i.e backup the underlying storage volume via NDMP. This has the same disadvantage as earlier, incremental backup size being same as full. The 'esx way' to do backups, is VCB - in which case, you have to write scripts and have a dedicated server to act as VCB backup server. The main advantage to this being incrementals are really incrementals.
Is it required to go through the pain of setting up VCB backups (maybe that is the reason most of VMWare backups are not done this way)? A recent approach to handle this trouble is to implement 3rd party software to do backups at block level incremental which really seem to be saving lots of trouble and backup size. But wait, if it is that simple why isn't everyone implementing it? Maybe there is a downside to it? Well, what is not advertised with these products is that they add a very-high amount of load on your primary storage thereby making all the VMs suffer from disk resources and everyone ultimately blaming the storage admin for poor disk response and the architect for designing such a poor storage solution. These backup products claim to do a block-level de-duped incremental - which is true, but at the cost of having all the VMs suffer until that backup completes. The product does not have a true deduplicated repository and hence keeps scanning all the blocks in the VMDK (even empty blocks) for any changes. For example, if you have 500g of VMDK but using only 200g and the remaining is white space, all of 500g is now scanned for changed blocks - not once, but everytime a backup is done.
Due diligence need to be done before you choose whichever method you want to implement and make sure the storage guys are involved. This is not just a VMWare admin decision as it impacts other components and ultimately be the storage engineer resposibility to "fix" the problem. You might like the "deduped, block level backups" but you also need to understand what problems it might cause and how to tackle them.
If only there is a real product that can integrate into both ESX and Storage and can do "real" block level incremental with dedupe, that would be a great one. Since it involves storage, I would assume such a product to be coming from a storage vendor since they have insight into the workings of storage - both blocks and dedupe. The initial investment might be high, but you will be happy that you made it, especially with large VMWare deployments.
vSphere is coming out with a vmware-backup methodology that will help from a backup point as well some-kind of DR. They are not trying to make it a full-blown backup product for VMWare (at least not at this time), but if it matures into that, it would be a real help.
No comments:
Post a Comment