Server for backups: storage with RAID and encryption

A backup server is a specialized storage solution, most often a dedicated server, equipped with redundant disk arrays (RAID 1, 5, 6), powerful data encryption tools, and optimized for automated backup using tools like Borg, Restic, or rsync.

In today's digital world, data is one of the most valuable assets for any company or private user. The loss of critical files due to hardware failures, cyberattacks, human error, or natural disasters can lead to catastrophic consequences, up to and including the complete cessation of business operations. This is why creating a reliable backup server is not just a recommendation, but a mandatory element of an information security strategy.

In this article, we will take a detailed look at how to build an effective backup server, what technologies to use to ensure data integrity and confidentiality, and how to choose the right hardware for your needs.

What is a backup server and why is it critically important for business?

Backup server is a server designed exclusively or primarily for storing backup copies of data from other systems. Its main task is to ensure data availability and integrity in case of loss on the original source. This can be either a physical dedicated server or a powerful VPS, depending on the volume and performance requirements.

The critical importance of such a server is due to several factors:

• Data Loss Protection: The primary function is to restore information after failures.
• Business Continuity: Rapid data recovery minimizes downtime and financial losses.
• Regulatory Compliance: Many industries have strict requirements for data storage and protection, including regular backups.
• Protection Against Cyberattacks: Backups, especially isolated (offsite) ones, can be the only way to recover after ransomware attacks.

A properly configured backup storage server must be reliable, secure, scalable, and easy to manage.

Which RAID to choose for a backup storage server?

RAID (Redundant Array of Independent Disks) is a technology that allows combining multiple physical disks into a single logical volume to improve performance, fault tolerance, or both. For a backup storage server, fault tolerance is a priority.

Main RAID types suitable for backups:

• RAID 1 (Mirroring): Two disks operate as a mirror of each other. If one disk fails, data remains on the second. Excellent fault tolerance, but 50% of disk space is lost. Read speed is high, write speed is like a single disk. Ideal for small but very critical data volumes.
• RAID 5 (Striping with Parity): Requires a minimum of three disks. Data is distributed across all disks along with parity blocks. Can withstand the failure of one disk without data loss. Efficient space utilization (N-1 disks), good read speed, but write speed can be slower due to parity calculation. A popular choice for balancing cost, performance, and reliability.
• RAID 6 (Striping with Dual Parity): Requires a minimum of four disks. Similar to RAID 5, but uses two parity blocks. Can withstand the failure of two disks. Even higher fault tolerance, but slightly less efficient space utilization (N-2 disks) and slower write speed compared to RAID 5. Recommended for large data volumes where the risk of simultaneous failure of two disks is not zero.
• RAID 10 (1+0): A combination of RAID 1 and RAID 0. Requires a minimum of four disks. Data is mirrored, and then the mirrors are striped. High read/write performance and excellent fault tolerance (can withstand the failure of multiple disks if they are not mirrors of each other). However, 50% of disk space is lost, making it an expensive solution for large backup volumes.

For most backup storage server scenarios, RAID 5 or RAID 6 are optimal, depending on the data volume and the required level of fault tolerance. If you have a limited budget but the data is very important, RAID 1 is suitable for smaller volumes.

Comparison of RAID Arrays for Backup

Data Encryption: Protecting Your Offsite Backup Server

Encryption is the cornerstone of security for any offsite backup server. Without encryption, your confidential data can be compromised in the event of unauthorized server access or physical disk removal. Encryption protects data both "at rest" (on disk) and "in transit" (during transfer).

Encryption Methods

1. Filesystem or Container-level Encryption:
   • LUKS (Linux Unified Key Setup): Allows encrypting entire partitions or disks. This is one of the most reliable methods for encryption "at rest". When the server reboots, a password is required to unlock the disks.
   • eCryptfs: Filesystem-level encryption, often used for encrypting a user's home directory.

   Example of creating an encrypted partition with LUKS:

   sudo cryptsetup -v luksFormat /dev/sdX1
   sudo cryptsetup -v open /dev/sdX1 my_encrypted_backup
   sudo mkfs.ext4 /dev/mapper/my_encrypted_backup
   sudo mount /dev/mapper/my_encrypted_backup /mnt/backup

2. Backup Application-level Encryption:
   • Borg Backup and Restic: These tools have built-in encryption mechanisms that encrypt data before it is written to disk. This is convenient because encryption occurs on the client side, and already encrypted data is sent to the server. The encryption key never leaves the client machine.
   • GnuPG: Can be used to encrypt individual files or archives before sending them to the server.
3. Data in Transit Encryption:
   • SSH/SFTP: Always use secure protocols for transferring data to an offsite backup server. SSH encrypts all traffic between the client and the server.
   • VPN: Creating a VPN tunnel between the data source and the backup server adds an additional layer of protection.

The choice of method depends on your security and convenience requirements. A combination of LUKS for full disk encryption and built-in Borg/Restic encryption provides maximum protection.

How to calculate the required capacity for a backup server?

Calculating the capacity for a backup server is a critically important step that will help avoid future space shortage issues. It involves several factors:

1. Initial Data Volume: How much data do you need to back up right now? (e.g., 1 TB).
2. Data Growth Rate: How quickly is your data volume increasing? (e.g., 10% per year or 50 GB per month).
3. Retention Policy: How long do you plan to store backups?
   • Daily backups for the last week.
   • Weekly backups for the last month.
   • Monthly backups for the last year.
   • Annual backups for the last N years.

   The longer the retention period and the more frequent the copies, the more space will be required.

4. Backup Type:
   • Full: Each copy contains all data. Requires a lot of space.
   • Incremental: Only changed data since the last backup (full or incremental) is copied. Very space-efficient, but recovery takes longer.
   • Differential: All changes since the last full backup are copied. Takes more space than incremental, but recovery is faster.

   Modern tools like Borg and Restic use deduplication and compression, which significantly reduces the required volume.

5. Compression and Deduplication Ratio:

   When using Borg or Restic, data can be compressed and deduplicated. The compression ratio can vary from 1.5x to 5x or more, depending on the data type. Deduplication eliminates storing identical data blocks multiple times, further saving space.

   Example: If you have 1 TB of data that grows by 100 GB per month, and you want to store 30 daily incremental copies, 4 weekly, and 12 monthly, without deduplication this would require a huge amount of space. With deduplication and compression (e.g., 2x), 1 TB can turn into 500 GB, and incremental changes will take up much less.

   Formula for a rough calculation:

   Total_Capacity = (Initial_Data_Volume / Compression_Ratio) * (1 + (Number_of_Incremental_Copies * Average_Incremental_Size / Initial_Data_Volume)) * RAID_Redundancy_Factor

   This is a very simplified formula. In practice, it's better to start with 2-3x the initial data volume for comfortable storage of backups over several months, considering deduplication, and then monitor usage and scale storage.

   For large data volumes, consider a dedicated server with a large disk.

Backup Tools: Borg, Restic, and rsync server

Choosing the right backup tool determines the efficiency, speed, and reliability of the entire system. Let's look at three popular solutions:

Borg Backup Server

Borg Backup is a powerful, efficient, and secure tool for deduplicated backups. It stores data in encrypted, compressed, and deduplicated archives. This makes it ideal for a borg backup server.

• Deduplication: Borg breaks files into chunks and stores only unique chunks. If you have many versions of a single file or several similar files, Borg significantly saves space.
• Compression: Supports various compression algorithms (zlib, lz4, zstd).
• Encryption: Built-in AES256-CTR encryption, protected by a passphrase or key. Data is encrypted on the client before being sent to the server.
• Remote Storage: Works over SSH, simplifying the setup of an offsite backup server.
• Archive Mounting: Archives can be mounted as a regular filesystem for easy recovery of individual files.

Example of using Borg:

# On the backup server (borg server)
# Install Borg (example for Debian/Ubuntu)
sudo apt update && sudo apt install borgbackup

# Create a repository
borg init --encryption=repokey-blake2 /path/to/backup/repo

# On the client
# Create the first backup
borg create --stats --progress ssh://user@your_backup_server:/path/to/backup/repo::my-first-backup /home/user/data /var/www

# Create subsequent incremental backups
borg create --stats --progress ssh://user@your_backup_server:/path/to/backup/repo::my-daily-backup-{now} /home/user/data /var/www

# Delete old backups according to policy
borg prune -v --list --keep-daily=7 --keep-weekly=4 --keep-monthly=6 ssh://user@your_backup_server:/path/to/backup/repo

Restic

Restic is another modern, secure, and efficient backup tool, very similar to Borg. It also uses deduplication, compression, and encryption.

• Content-addressable storage: Restic stores data by its hash, which ensures efficient deduplication and integrity checking.
• Encryption: Built-in AES-256 encryption in CTR mode using Poly1305 polynomial hashing.
• Multiple Backends: Supports storage on local disks, SFTP, and also in cloud storage (S3, Azure Blob Storage, Google Cloud Storage, etc.).
• Integrity Check: Regular integrity checks of the repository.

Example of using Restic:

# On the backup server or in cloud storage
# On the client
export RESTIC_REPOSITORY="sftp:user@your_backup_server:/path/to/backup/repo"
export RESTIC_PASSWORD="your_strong_password"

# Initialize the repository
restic init

# Create a backup
restic backup /home/user/data /var/www

# View snapshots
restic snapshots

# Delete old backups
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

rsync server

rsync is a classic, highly efficient tool for synchronizing files and directories. It does not have built-in deduplication or "at rest" data encryption, but it is very good for transferring changes between two points.

• Incremental Transfer: rsync transfers only changed parts of files, saving bandwidth and time.
• Flexibility: Can operate over SSH or via its own protocol (rsync daemon).
• Simplicity: Easily configured for basic scenarios.

Example of using rsync:

# Synchronize a local directory with a remote server via SSH
rsync -avz --delete /home/user/data/ sshuser@your_backup_server:/mnt/backup/data/

# Where:
# -a: archive mode (recursively, preserves symbolic links, permissions, times, groups, owner)
# -v: verbose output
# -z: compress data during transfer
# --delete: deletes files on the receiver if they are not present on the sender

To create a full-fledged rsync server, you can run the `rsyncd` daemon on the server side with the appropriate configuration in the `/etc/rsyncd.conf` file. However, for most tasks, an SSH tunnel is sufficient and more secure.

The choice between Borg/Restic and rsync depends on your needs. For long-term, deduplicated, and encrypted storage, Borg or Restic are preferable. For fast synchronization or creating an initial "seed" backup, rsync is indispensable.

3-2-1 Strategy and Offsite Backup Server Placement

The 3-2-1 strategy is the gold standard for backups. It states:

1. Have at least 3 copies of your data (original + 2 backups).
2. Store copies on 2 different types of media (e.g., HDD and cloud storage, or HDD and NAS).
3. Keep 1 copy offsite, away from the primary data storage location.

An offsite backup server is needed precisely to fulfill the third point. Placing a dedicated server in a different data center or geographical location protects your data from local disasters such as fires, floods, power outages, or physical attacks on the main office.

Valebyte offers dedicated servers in various locations, making it easy to implement an offsite strategy. You can have your primary server in one country and your backup server in another, for example, in Germany or the Netherlands, ensuring maximum geographical redundancy.

Choosing a Dedicated Server for Backups: Characteristics and Prices

Choosing the optimal dedicated server for backups requires attention to several key characteristics:

1. Disk Subsystem: This is the most important component.
   • Disk Type: HDDs (SATA/SAS) for maximum capacity and cost-effectiveness. SSDs (NVMe/SATA) can be used for storing Borg/Restic metadata or for backups requiring high recovery speed, but their cost per gigabyte is higher.
   • Capacity: Calculated based on your needs (see section above). A 20-30% buffer is recommended.
   • RAID Controller: A hardware RAID controller significantly outperforms a software one in terms of performance and reliability, especially for RAID 5/6.
2. Random Access Memory (RAM):
   • For Borg/Restic: The more RAM, the more efficiently deduplication works and the faster archive indexes are built. For 1-2 TB of data, 8-16 GB of RAM is sufficient; for larger volumes (10+ TB), 32 GB or more is recommended.
   • For rsync: Less critical, 4-8 GB is usually sufficient.
3. Processor (CPU):
   • For compression and encryption: Modern multi-core processors (e.g., Intel Xeon E3/E5 or AMD EPYC) will handle these tasks quickly. For most backup tasks, a top-tier CPU is not necessary, but having multiple cores with a good clock speed will accelerate processes.
4. Network Interface:
   • Speed: 1 Gbps is standard, but if you need to transfer large volumes of data quickly, a 10 Gbps port will significantly speed up the process. Keep in mind that channel speed is also limited by the bandwidth of your data source.
   • Traffic: Pay attention to the traffic limits provided by the hosting provider. Backups typically require a large volume of outbound traffic during recovery and inbound traffic when creating copies.

Example Configurations of Dedicated Servers for Backups

Below are example configurations suitable for various scales of backup tasks. Prices are approximate and may vary.

To choose a suitable solution, we recommend checking out our guide on choosing a dedicated server, as well as information on what to choose: VPS or dedicated server.

Recommendations for Setting Up and Maintaining a Backup Server

Setting up and regularly maintaining a backup server ensures its reliability and efficiency:

1. Automation: Set up scripts for automatic backup execution on a schedule (cronjobs). Human error is a common reason for missed backups.
2. Monitoring: Implement a monitoring system that tracks disk status (SMART), free space, backup job success, and repository integrity (e.g., borg check or restic check). Failure notifications should arrive immediately.
3. Recovery Testing: Regularly (monthly or quarterly) perform test data recoveries from backups. This is the only way to ensure your copies are truly functional.
4. Security:
   • Use SSH keys instead of passwords for server access.
   • Disable password login for SSH.
   • Change the default SSH port.
   • Configure a firewall (e.g., UFW or iptables), allowing access only from trusted IP addresses and only on necessary ports.
   • Regularly update the OS and all software on the server.
5. Documentation: Thoroughly document all settings, backup and recovery procedures, and the location of encryption keys and passwords.
6. Encryption Key Management: Store encryption keys in a secure location, separate from the backup server. Losing a key is equivalent to losing data.

Conclusion

A reliable backup server is an investment in the stability and security of your business. Choosing a dedicated server with a suitable RAID array, effective encryption, and powerful tools like Borg or Restic ensures maximum data protection. Don't forget the 3-2-1 strategy and regular testing to ensure your backup server is always ready for action.