When it comes to choosing a backup mode in Veeam Backup & Replication,there is a constant trade-off between space efficiency and I/O efficiency. Forward mode is I/O efficient, while Reversed is space efficient. The new method coming in v8 will combine the pros of each, to offer an even better backup experience.
One of the biggest misconceptions about Veeam Backup & Replication, often fueled by competitors, is that it requires the complete server installation in order to run restores. So, this becomes a Single Point of Failure, just like many other solutions from competitors. This is completely untrue: there are two main features in Veeam that make restores possible even without the server installation.
Veeam Backup & Replication has always had since its first version the possibility to replicate VMs, together with the backup capabilities. Once a VM is replicated in a secondary site, it could become a great resource for additional activities: from automated recovery tests (called SureReplica in Veeam) to become also the source for cloning activities. Data are already locally saved, there is no need to retrieve anything else from the source site, so any operation is quick an easy. Are there any informations we should be aware of in doing these operations? Let’s find it out.
Instant VM Recovery is one of the coolest feature of Veeam Backup & Replication. Regardless of the size of a VM, it allows to have it back in production and running in few minutes, because it’s not actually copied back into the production datastore, but directly executed from a backup file. It’s main use is to restore completely broken or lost VMs, but what if you want to restore a single VMDK, maybe because the original VM is fine and you only need one of its virtual disks? usually, a disk restore would require a complete binary restore into the production datastore, and if the disk is quite large it can take some time. What if you would be able to use Instant VM Recovery also for a single VMDK, instead of having to remove the old VM and swap it with the new one?
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!
One of the new features introduced in Veeam Backup & Replication 7.0 is the new “Backup Copy” job type. With it, an administrator can create a secondary location for his backups, without having to clone large backup files from the primary backups using tools like rsync or robocopy.
If you plan to use an external USB drive as your target for this kind of jobs, be sure to check the file system in use, before runnng into problems.