I’ve seen often Veeam users to configure their repositories using administrative permissions. This is a really bad practice as the most precious part of a Veeam environment, the backup files, are then exposed to security risks, in case anyone can obtain those credentials. And with the raise of cryptolockers and ransomware this behavior has become even more dangerous. For Linux repositories, users can configure their servers to use common users.
Veeam Agents, both for Windows and for Linux, have the possibility to send backups to a Veeam Backup & Replication server. This is a great feature, but sometimes customers don’t even have anymore any virtualized workload to protect, so they find a hard time to justify the deployment of Veeam Backup & Replication to only protect physical workloads. There’s a solution to this however, and it doesn’t cost anything to users.
There has been a lot of discussions about ReFS 3.1 after Veeam released its version 9.5 with support for the block clone API. With this integration between the two product, users can now design a repository that combines the speed of a non-deduplicated array, with some important space savings that usually belongs to those dedicated appliances. We have seen many many discussions in our Veeam forums, and I also published two articles on this topic you may want to read: Windows 2016 and Storage Spaces as a Veeam backup repository and An example for a Veeam backup repository using Windows 2016.
Now that people are starting to use ReFS, another question has risen: which cluster size should I use? 64KB or 4KB?
In my previous article Windows 2016 and Storage Spaces as a Veeam backup repository I talked about the advantages that Veeam Backup & Replication can bring when combined with Windows Server 2016 and the new ReFS 3.1 filesytem. Several people have asked already about some practical examples about how to design a solution using these technologies, so I thought it was time to give you one storage design.
As Microsoft Windows 2016 is now finally generally available, people are starting to seriously looking at its features, and no doubt S2D together with the new ReFS 3.1 is one of the hot topics. I’ve first of all updated my lab with the final version of Windows 2016 in order to have my cluster in a “stable” state, than I started to focus on the different topics related to Windows 2016 and its usage as a Veeam repository. And I started to ask How can we leverage ReFS BlockCloning and Storage Spaces to make Windows 2016 the best solution for Veeam repositories? What about Storage Spaces Direct?”.
It’s no doubt Scale-out Backup Repository is one of the biggest and most talked new feature of Veeam Backup & Replication v9. I wrote a new whitepaper to guide readers in exploring and learning how to get the best out of this new exciting technology.
Since Veeam announced the Scale-Out Backup Repository technology coming in Veeam Backup & Replication v9, I’ve been asked already multiple times to give some practical examples on how to leverage it. Let’s see together one interesting way to leverage the “performance” policy available in Scale-Out Backup Repository.
A new species of Backup Repository is coming from Veeam: Scale-Out Backup Repository. With it, users will be able to simplify backup job management, improve backup performance, and spend less on backup storage. Veeam’s new Scale-out Backup Repository delivers these benefits by providing an abstraction layer over individual storage devices, effectively creating a single virtual pool of backup storage to which you can assign backup jobs, and offering the freedom to easily extend capacity as needed by simply adding additional storage devices into the existing pool.