If you want to use CentOS 7 as a Veeam repository, the basic requirements are not enough, and you have to adjust the installation a little bit.
When you upgrade Veeam Backup & Replication to V8, you have available the new Forward forever-incremental mode for your backups. This is the default method for all newly created jobs, but the already existing backup jobs are not changed, because we do not want to change the user experience or create issues to I/O profiles, backup windows and such.
This great powershell script will take all your existing forward incremental backup jobs and reconfigure them to use the new forward forever-incremental mode.
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.