In an ever-expanding digital era, cyber threats are becoming increasingly sophisticated and widespread, undermining the security of both personal and organizational information. From malware and ransomware attacks to data breaches, the challenges we face are diverse and unpredictable. In this context, backup emerges as the essential last line of defense, protecting data against accidental loss and cyberattacks and ensuring that critical information can be recovered quickly and efficiently. Recently, the adoption of the NIS2 Directive (Network and Information Systems Directive) and the DORA regulation (Digital Operational Resilience Act) highlights the importance of a robust security infrastructure that includes appropriate backup measures. These regulations emphasize the need to protect systems and data against cyber incidents and to ensure business continuity in the face of various threats.

Implementing a backup solution does not always guarantee that its purpose will be fulfilled. To address this, I will highlight certain factors that can influence a successful implementation.

The first step that should be taken is a clear definition of the solution implementation design, in which available resources are identified, requirements and constraints are established and assumptions are eliminated. The infrastructure that will be protected is identified:

• Data centers (physical locations)
• Virtual infrastructure (vSphere, Hyper-V, AHV, RHV, etc.)
• Physical machines
• Cloud machines
• Unstructured data (File shares, NAS, object storage)
• Databases

The implementation requirements follow business needs or technical needs and are translated into functional or non-functional requirements, which must be documented:

• Service Level Agreements (SLA) and Service Level Objectives (SLO)
• Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO) – examples: databases, RPO – 0.5 TB per hour; NAS, RTO for a single file < 1 hour; server (physical or virtual), RTO < 24 hours
• Retention – the time period available for restoration
• Consistency – consistent backup of applications: MS-SQL, Oracle, AD, etc.
• Immutability – the ability to store backup data without the possibility of modification or deletion
• 3-2-1 rule – backup strategy to keep 3 copies of data, on 2 different backup media (disk, tape, cloud), with 1 offsite backup copy
• Backup window – ensuring that the backup is completed within a defined time period
• Backup encryption – during storage and transmission over the network
• Resilient backup – data copies stored on reliable, redundant media with vendor support
• Compression and deduplication
• Ransomware/malware mitigation – functions implemented to reduce risks and impact of cyberattacks
• Replication – replication for critical systems
• Security requirements – MFA for login to the backup console, restricted access to the backup server, etc.

Another component of the solution design is constraints, which arise at the level of description, implementation or operation:

• Network infrastructure – transport capacity determined by communication equipment or the communication provider
• Backup storage equipment – must not be EOL (End of Life) to benefit from manufacturer support
• Backup operation start time – to avoid disrupting production activities
• Existing storage capacity
• Available budget
• Implementation time
• Experience and competence of the implementation team

In addition to all these aspects, there are other elements that must be considered in the design process, but they will be assumed:

• Database modification rate
• Virtual machine growth rate
• Deduplication rate
• Data compression rate
• Increase in internet network bandwidth

The implementation of a backup solution can also come with certain risks that need to be considered. Here are some potential risks:

• Short implementation deadlines
• Incorrect estimation of required storage equipment, based on compression and deduplication
• Exceeded equipment delivery deadlines
• Solution implementation on outdated hardware

The next step, after completing the conceptual design, is to develop the logical design. Its purpose is to select the application components based on the previously specified requirements and is finalized by creating an HLD (High-Level Design), in which the Backup & Restore application components and their sizing will be documented.

Example of architecture

In general, a backup solution should have at least the following components, depending on the requirements.

Backup server, which can be a physical or virtual server, installable on various operating systems, with CPU and RAM depending on the size of the backup solution. For the backup server, the following aspects should be considered:

• Restricting access to the server, including remote access tools
• Not belonging to the same domain as the machines it backs up
• Avoiding unnecessary applications on the server
• Installing the backup application console on an auxiliary server, instead of directly on the backup server, to prevent RDP access
• Implementing multi-factor authentication (MFA)
• Activating four-eyes authorization, meaning configuration and backup job modifications must be approved by two people
• Allowing only the necessary ports for the application
• Configuring and encrypting the backup copy of the application’s configuration
• Disabling outdated versions of SSL (SSL 1.0, 2.0, 3.0) and TLS (TLS 1.1)

Backup server database, which can exist on the same server as the application or on a separate dedicated database server, installable on various operating systems, with CPU and RAM depending on the size of the backup solution. This component must be secured just like the backup server.

Network component: IP addressing, DNS, traffic encryption, network segmentation for application components.

Backup repository, the storage equipment designated for backup copies. Depending on the requirements, it can be FC SAN, Shared SAS, iSCSI SAN, NFS, vSAN, vVOLs, object storage, or local storage. An important aspect is sizing this component properly:

• From a compute resource perspective:

CPU cores = RoundUp (Proxy Cores /3), where proxy core can be a proxy for VMware, CDP, or for each physical agent (each physical agent acts as its own proxy).

RAM in GB = Required Repository CPU cores * 4

• From a storage perspective, each application has its own calculation tool:

For full backup: capacity = Size of Full Backup (TB) * (Total Instances * Full Backups Per Week) * Annual Growth Rate

For incremental backup: capacity = Number of incremental backups per week * IncSizeGB / 1024 (GB to TB) * Compression formula

Backup proxy, a component of the backup infrastructure that manages backup and restore traffic, optimizing the process to reduce the impact on system resources. It can be configured to perform data compression and encryption, as well as route backup traffic to the appropriate destination. For proxy sizing estimation:

For CPU: Required Incremental Proxy CPU cores = ((Source Data Size MB * Change Rate) / Backup Window Sec) / Throughput per Task MBps

For RAM: Required RAM in GB = Required Incremental Proxy CPU cores * 2

Gateway server, an auxiliary component of the backup infrastructure that facilitates access from the backup server to backup storage, where the backup server cannot reach directly (for example, access to object storage in the cloud).

Mount server, a backup infrastructure component that manages the mounting and access to backup files for restoration or verification. It allows users to browse and recover data from restore points without needing to download the entire backup.

The next step is the implementation of the solution, following the installation document provided by each vendor. The implementation team must verify the solution’s functionality according to the designed tests.

Validation tests must include specific actions, involved components, test parameters and expected results. Among the aspects that need to be tested are:

• User access (permissions)
• Job execution (duration)
• Workload protection
• Received notifications
• Backup file location (compliance with the 3-2-1 rule)
• RPO (Recovery Point Objective)

The implementation is not complete until the restore component is validated. The following elements are restored:

• Application elements
• Files and folders of the guest operating system
• Virtual machines
• Agent backups
• Failover and failback of replication
• Files, folders, and devices from NAS/object storage
• Virtual machine recoverability
• Application recoverability
• Application dependencies
• Backup file integrity
• Backup content (malware scanning)

Data backup and protection is an ongoing process. There are a series of strategic steps for reviewing and updating implementation processes:

• Reviewing deployment notes. Checking recorded notes from previous implementations to identify issues and necessary modifications at the physical design level.
• Updating documentation. Completing existing documentation by adding missing steps or recommendations to overcome environmental challenges encountered during implementation.
• Periodic evaluation of the environment’s status. Collaborating with the administration team to regularly monitor the environment, ensuring everything functions as expected and identifying potential areas for improvement.
• Identifying new initiatives and changes. Paying attention to new initiatives or operational environment changes that may trigger the need for a new implementation cycle.
• Reviewing changes in the product suite. Periodically assessing whether product suite updates address new or existing business challenges, determining areas for optimization or best practice adoption.

These steps contribute to the maintenance and continuous improvement of existing implementations, ensuring their adaptation to the dynamics of the organizational and technological environment. If you would like to discuss in more detail how these practices can be integrated into the professional context of your business, Arctic Stream is here to continue the conversation! You can contact us at: [email protected].