In the context of a customer project, I conducted a Veeam Advanced Deployment. The project’s objective was to enhance backup performance and security by distributing Veeam services across multiple virtual and physical systems.
The customer is a medium-sized company with a direct sales approach targeting large customers and its own development team.
The environment consists of both Windows and Linux systems, encompassing approximately 300 VMs with around 50TB of actively used storage.
The initial situation involves the customer operating a physical Dell R750 server with local HDDs (10 units, each with 20TB gross capacity) as a standalone backup server. The server is connected to the existing iSCSI SAN via 4x 10Gbit links (with up to 25Gbit possible within the SAN) and achieves the following processing rate during backups:
What exactly can be a bottleneck or a security risk here?
- The full stripe size of the HDD RAID on the backup server is not set to 1MB, which is recommended both by the manufacturer and Veeam’s best practices.
- MPIO (Multipath I/O) is not correctly configured on the server.
- Additional software (e.g., two web browsers, etc.) is installed on the backup server.
- The server is in the same subnet/VLAN as the rest of the productive infrastructure.
- There is no redundancy – if the backup server fails, there will be no access to the data or the Veeam environment itself.
- The customer exclusively uses the local administrator of the Windows server to access the Veeam environment.
- The server has full internet access and is accessible from anywhere within the LAN.
What does the new solution look like?
- The implementation of separate VLANs for different services.
- A strong integration of a firewall rule set.
- Hardening of access through up-to-date password and user policies.
- Permission allocation based on the principle of least privilege.
- Personalization of user accounts.
- Integration of the physical backup server into the SAN, including the implementation of best practices.
- RAID design following the manufacturer’s best practices.
- Veeam Advanced Deployment.
Installation PostgreSQL 15:
PostgreSQL has been installed at the customer’s site in the latest version, along with the ODBC driver, and a dedicated service account has been created specifically for Veeam usage. This account has the following permissions:
Tests in the past have revealed that recurring issues arise when the service account is not declared as a superuser. Currently, this is considered a temporary solution. However, the absence of the role itself prevents Veeam from creating a new database, even though the „Create databases“ privilege is granted!
Note: When migrating existing MSSQL scenarios, it’s important to ensure that the default settings are largely retained. Specifically, the database name (target database in Postgres) should not be changed, as it can lead to errors!
iSCSI Configuration on the physical proxy server:
The physical backup server has been connected to the existing iSCSI SAN with 4x 10Gbit links and has been added as a host on the storage cluster. The server has visibility of every LUN from the storage systems in a read/write mode. In accordance with current best practices, the automount feature in Windows has been deactivated:
Configuration VMware Proxy:
Here, the VMware proxy has been configured within Veeam. This is a dedicated server, as described, equipped with two physical CPUs.
Configuration Backup Repository:
The physical server is equipped with local HDDs, serving as the primary repository for Veeam. Consequently, it functions both as a proxy and a repository.
Editing the local security policy:
The approach here follows the logic that on the respective Windows servers responsible for providing the Veeam infrastructure, local service accounts are used. These service accounts, for instance, do not require any Remote Desktop Protocol (RDP) permissions. The following security setting in the local security policy has been configured:
Conversely, a service account naturally requires the permission to execute services; therefore, the following setting has been applied:
Since, unfortunately, until Windows Server 2022, local administrators are allowed to use RDP by default (if enabled), RDP access has been restricted to the local „Remote Desktop Users“ group, and the local administrator has been added there. The following setting has been applied (local administrators have been removed here):
Map RBAC in Veeam:
The configurable permissions in Veeam have been represented as local Windows groups.
In the first phase, the customer prefers not to activate Multi-Factor Authentication (MFA) since the environment is currently within isolated VLANs, and they intend to implement this step as part of further hardening measures.
Configuration Agent Backups:
Since the customer only wants to back up a few clients and servers using agents, the following two Protection Groups have been created:
In this scenario, the relevant backup jobs have been created using the Protection Groups. The clients are manually added to the Protection Groups by the customer.
Configuration Tape Server:
Aligned with the customer’s desired backup strategy, the Media Pools „Daily“ and „Monthly“ have been established for the daily and monthly backup tapes. The „Unrecognized“ Media Pool contains all cleaning tapes:
Summary / general overview:
Finally, all jobs were meticulously created and tested (screenshot taken before completing all tests). In principle, the jobs were created based on vSphere tags. The concept is that each VM only requires one tag for seamless assignment within Veeam.
The performane has increased significantly:
Priority of labels:
In all of my installations, I place great emphasis on clean and detailed labeling. The rationale behind this is that both the customer and any service provider’s staff can quickly gain an overview, which, in turn, facilitates faster troubleshooting for the customer and provides a better foundation for documentation:
