Overview

XReplicator includes security controls for backup data in transit, at rest, and against accidental or malicious backup tampering.

Implemented controls include:

• TLS for backup agent, backup server, and web dashboard gRPC communication
• Optional mTLS with client certificates for agents and the web dashboard
• Immutable retention window for restore points
• S3 Object Lock, Azure Blob immutability, and GCS retention support
• Checksum verification for chunks and restore manifests
• Restore verification modes: metadata, sample, and full
• Auto verification after backup
• Block churn anomaly detection for ransomware-style change spikes
• Last-known-clean restore point suggestion
• Security audit events for restore, delete, retention, user, credential, and verification actions
• Operation history and monitoring charts for restore verification and churn anomalies

TLS and mTLS Model

Use one private CA to sign:

• server.crt / server.key for the backup server
• client.crt / client.key for each backup agent
• optionally a separate dashboard client certificate for the web UI process

The server certificate must include the DNS name or IP address that agents and the web dashboard use in server_address / BACKUP_GRPC_ADDRESS.

Generate Certificates

Use real DNS/IP values for your deployment. The example below avoids shell process substitution so it works in minimal shells and under sudo.

sudo install -d -m 755 /etc/backup/tls
cd /etc/backup/tls
 
# CA
sudo openssl genrsa -out ca.key 4096
sudo openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 \
  -subj "/CN=XReplicator Backup CA" \
  -out ca.crt
 
# Server certificate
sudo openssl genrsa -out server.key 4096
sudo openssl req -new -key server.key \
  -subj "/CN=backup-server.example.com" \
  -out server.csr
printf "subjectAltName=DNS:backup-server.example.com,IP:192.168.5.2\nextendedKeyUsage=serverAuth\n" | sudo tee server.ext >/dev/null
sudo openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -out server.crt -days 825 -sha256 \
  -extfile server.ext
 
# Client certificate for agents / dashboard
sudo openssl genrsa -out client.key 4096
sudo openssl req -new -key client.key \
  -subj "/CN=xreplicator-client" \
  -out client.csr
printf "extendedKeyUsage=clientAuth\n" | sudo tee client.ext >/dev/null
sudo openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -out client.crt -days 825 -sha256 \
  -extfile client.ext
 
sudo chmod 600 /etc/backup/tls/*.key

Keep ca.key offline or on a restricted admin machine. Copy only ca.crt, client.crt, and client.key to agents and the web dashboard host.

Backup Server TLS Configuration

Edit /etc/xreplicator/server.yaml:

server:
  listen_addr: "0.0.0.0:50051"
  repository_path: "/var/lib/backup/repo"
  fixed_block_size_mb: 8
 
tls:
  enabled: true
  cert_file: "/etc/backup/tls/server.crt"
  key_file: "/etc/backup/tls/server.key"
  ca_file: "/etc/backup/tls/ca.crt"
  require_client_cert: true

Restart the server:

sudo systemctl restart backup-server
sudo journalctl -u backup-server -f

Agent TLS Configuration

Edit /etc/xreplicator/agent.yaml on Linux or C:\ProgramData\xreplicator\agent.yaml on Windows:

storage:
  type: "grpc"
  grpc:
    server_address: "backup-server.example.com:50051"
    timeout: 5m
    max_retries: 3
    tls:
      enabled: true
      cert_file: "/etc/backup/tls/client.crt"
      key_file: "/etc/backup/tls/client.key"
      ca_file: "/etc/backup/tls/ca.crt"
      insecure_skip_verify: false

Restart the agent:

sudo systemctl restart backup-agent
sudo journalctl -u backup-agent -f

Restart-Service XReplicatorAgent
Get-Service XReplicatorAgent

Web Dashboard TLS Configuration

The web dashboard connects to the backup server from its server-side API routes. Set these environment variables for the web process:

export BACKUP_GRPC_ADDRESS=backup-server.example.com:50051
export BACKUP_GRPC_CA_FILE=/etc/backup/tls/ca.crt
export BACKUP_GRPC_CERT_FILE=/etc/backup/tls/client.crt
export BACKUP_GRPC_KEY_FILE=/etc/backup/tls/client.key

Then restart the dashboard service/process.

If the dashboard reports unable to verify the first certificate, confirm that:

• BACKUP_GRPC_CA_FILE points to the CA that signed server.crt
• BACKUP_GRPC_ADDRESS uses a DNS name/IP present in the server certificate SAN
• the web process was restarted after changing environment variables

Backup Verification Parameters

Configure restore verification in /etc/xreplicator/server.yaml:

restore_verification:
  verify_after_backup: true
  mode: "full"              # metadata | sample | full
  max_parallel: 1
  max_runtime: "2h"
  max_snapshots_per_run: 0
  include_latest_only: true

Verification Modes

Ransomware-Resilience Settings

Immutable Restore Points

security:
  immutable_retention_window: 720h

During the immutable window, restore points cannot be modified or deleted by normal source-agent flows.

Block Churn Anomaly Detection

security:
  block_churn_anomaly:
    enabled: true
    high_change_percent: 80
    min_history: 3

Anomaly alerts appear in the Security Audit page and feed the last-known-clean restore point suggestion.

Object Storage Immutability

For off-site copies, enable object immutability on the storage target:

• S3-compatible storage: Object Lock with governance or compliance mode
• Azure Blob: immutability policy
• Google Cloud Storage: retention policy

Use immutable buckets/containers for ransomware-resilient off-site backup copies. Match the object-lock retention to your business recovery and compliance requirements.

Operational Guidance

• Use TLS everywhere in production.
• Use mTLS for agents and the web dashboard when the backup server is reachable over a shared or routed network.
• Keep CA private keys off agents and dashboard hosts.
• Use metadata or sample for frequent low-cost checks.
• Use full verification for critical systems and customer-facing recovery assurance.
• Monitor churn anomaly charts and audit events after suspicious activity.
• Keep immutable retention long enough to cover ransomware detection delay.