Virtual Volumes, or VVOLs, has been one of the biggest addition in VMware vSphere 6. If your storage array supports them, you can start to play with it and decide if it’s time to migrate from monolithic VMFS volumes to this new exciting storage technology. VVOLs have several advantages over regular VMFS volumes, from the granularity of the volume management (essentially, we have now one “LUN” per virtual disk), to policy-based management, and so on. One of the aspects that people didn’t focused too much is the impact on backup operations coming from VVOLs.
Lately, different bugs involving VMware CBT in vSphere 6 have created some justified concerns among users. But there are ways to guarantee successful backups even in these conditions.
PernixData is, as of today, the only server-side caching solution for VMware offering write-back capabilities, that is the possibility to accelerate write operations. This feature is extremely helpful in increasing performances in virtualized environments running write intensive applications like databases, mail servers and others. However, the usage of this feature requires some proper configuration in order to correctly protect VM with Veeam Backup
In a previous post, I described how you can configure a virtual proxy to access an iSCSI storage, in order to test DirectSAN backups. Veeam has an additional functionality, called Storage Snapshots, that improves even more DirectSAN backups performances when you have a supported storage. I’m going to show you in this post how you can configure it in your lab.
One of the nice features of Veeam Backup & Replication, when it comes to backup speed, is the possibility to use DirectSAN as its backup method on vSphere environments. This option offers the best performances, but has some precise requirements at the hardware level. It could be easy to comply with them in a production environment, but what if you want to test it in your lab, where usually hardware options are limited? Don’t worry, there is a solution!
In vSphere 5.5 vStorage API for Data Protection (VDDK 5.5) will be available only in the 64 bit version. If you are using still 32bit machines to run your Data Protection solution, you better upgrade them to 64 bit.
Lately, many design projects I had had data protection as their main topic: VMware backups, remote backups, long-time retention, replicas, Disaster Recovery and so on. While I was reading customer’s requirements for his “data protection”, the most frequent has been always two: higher backup speed than his current solution, often based on “classic” backup software […]
What is the biggest size of a VMDK file? “2TB – 512 bytes” This has always been the official answer, and you would find this same answer in blogs, VMware communities, and other sources. The fact is: this answer is completely correct, but in a “real world environment” is wrong. No, I’m not going nuts, […]