More transparency, fewer hardware restrictions, freedom of choice, clarity of control, and immutability — that’s where backups are headed. Microsoft has been taking too long to adapt its ReFS to those consumer demands. Veeam and Linux, on the other hand, leverage those trends and offer immutability with reasonable freedom of object and cloud storage choice.
Part 2 discussed adding the Linux server to Veeam managed servers and adding immutable repositories, along with incompatible configs that Veeam’ll block if you try using them. Today, you will learn about the entire configuration deeper: how immutability works, scenarios with bad actors, how they can succeed, and how to test if all is working fine.
Part 1 discussed what a hardened repository was, how Veeam B&R V11 had everything to achieve that, and how to set up Linux for those purposes. Now, you will learn how to add the Linux server to Veeam managed servers and how to add immutable repositories. You’ll also learn about incompatible configs that Veeam will block if you try to use them.
Veeam Backup & Replication V11 introduced the ability to build your own immutable, hardened backup repository. There’s no more need to use third-party compatible solutions, like WORM disk storage or others. Now, you can do that using any server with storage that meets the requirements plus several supported Linux distros and XFS.
Contemporary Enterprise-grade environments have all-out unstoppable demands. Apart from exceptional redundancy and uptime, such infrastructures need impeccable backup. It must be in a hardened, non-domain joined setup that’s independent of the fabrics and workloads it protects, abide by the 3-2-1 rule, and have a small footprint.
In the previous part, the article focused on the design of HA SMTP relay solutions. It also outlined the steps you should take to correctly prepare for setting up. In this part, you will get the detailed step-by-step guide on how to actually set up the solution without any trouble. The process is cumbersome but manageable.
This article is part one of a two-part series on configuring a highly available, on-premises SMTP relay solution. In this part, we discuss the design and do all the preparational work before setting up the actual SMTP relay solution in part two.
In Part I of this article, we discussed how to handle multiple SSL sites sharing the same IP address and port bound to multiple SSL certificates in regards to SNI decryption and re-encryption with Kemp LoadMaster. We discussed briefly how to achieve this creatively. With Kemp LoadMaster, you will need to leverage sub-virtual services (SubVSs) in combination with content rules to handle this scenario. We also use SSL decryption and re-encryption in order to support the clients and servers with different TLS versions. Re-encryption is handled at the virtual service (VS) level, not at the SubVS level. Meaning you can only enter one SNI name for re-encryption with a shared VIP. So, in the case of two or more SSL sites sharing the same IP address, you would have only one that works.
As you all know by now, it really is time to say goodbye to TLS 1.0/1.1. You might be ready to only offer and support TLS 1.2. Perhaps you can even add TLS 1.3 as well. Being able and willing to block TLS 1.0/1.1 is a good thing completely. Well done.
Probably, everyone asked that question when finding out about the support function for persistent memory disks inside a virtual machine (VM) in Windows Server 2019 with the Hyper-V role. Persistent memory disks are good when we need a very high speed and very low latency. Some vendors can provide persistent memory disk option for you in their storage offerings. But why mapping persistent memory storage via the hypervisor host is so important?
