Setting Up LXD on a

Backups and Maintenance

Regular backups and timely maintenance are critically important for any production environment. LXD provides convenient tools for creating container snapshots, which significantly simplifies this process.

1. What to Back Up

• LXD Containers: Full snapshots of container state (file system, configuration).
• Data Inside Containers: Databases, user files, uploaded media files. Even with container snapshots, critically important data may require a separate backup for more frequent intervals or for restoring individual files.
• LXD Configuration Files: Profiles, network settings, global LXD settings.
• Host Configuration Files: /etc/fstab, /etc/network/interfaces (or netplan), /etc/ssh/sshd_config, firewall configuration, etc.

2. Simple Auto-Backup Script for LXD Containers

LXD allows creating snapshots (instantaneous images of the container's state). These can then be exported and stored in a secure location.

Let's create a script that will take snapshots, delete old ones, and export them.

#!/bin/bash

# Directory for temporary storage of exported snapshots
BACKUP_DIR="/var/backups/lxd_containers"
RETENTION_DAYS=7 # How many days to keep snapshots

mkdir -p "$BACKUP_DIR"

echo "=== LXD Container Backup Script ==="
echo "Starting backup at $(date)"

# Get a list of all running containers
CONTAINERS=$(lxc list --format csv --columns n)

for CONTAINER_NAME in $CONTAINERS; do
    echo "Processing container: $CONTAINER_NAME"

    # 1. Create a snapshot
    SNAPSHOT_NAME="backup-$(date +%Y%m%d%H%M%S)"
    echo "  - Creating snapshot '$SNAPSHOT_NAME'..."
    lxc snapshot "$CONTAINER_NAME" "$SNAPSHOT_NAME"

    # 2. Delete old snapshots
    echo "  - Cleaning up old snapshots for $CONTAINER_NAME..."
    lxc info "$CONTAINER_NAME" | grep "Snapshots:" | awk '{print $2}' | while read -r SNAP; do
        SNAPSHOT_DATE=$(echo "$SNAP" | cut -d'-' -f2 | cut -d'(' -f1) # Extract date from name
        if [[ -n "$SNAPSHOT_DATE" ]]; then
            SNAPSHOT_TIMESTAMP=$(date -d "$SNAPSHOT_DATE" +%s)
            CURRENT_TIMESTAMP=$(date +%s)
            DIFF_SECONDS=$((CURRENT_TIMESTAMP - SNAPSHOT_TIMESTAMP))
            DIFF_DAYS=$((DIFF_SECONDS / 86400))

            if (( DIFF_DAYS > RETENTION_DAYS )); then
                echo "    - Deleting old snapshot: $SNAP ($DIFF_DAYS days old)"
                lxc delete "$CONTAINER_NAME/$SNAP"
            fi
        fi
    done

    # 3. Export the latest snapshot (or all, if needed)
    # For simplicity, we export the current snapshot
    echo "  - Exporting snapshot '$SNAPSHOT_NAME' to $BACKUP_DIR/${CONTAINER_NAME}_${SNAPSHOT_NAME}.tar.gz"
    lxc publish "$CONTAINER_NAME/$SNAPSHOT_NAME" --alias "${CONTAINER_NAME}_${SNAPSHOT_NAME}"
    lxc image export "${CONTAINER_NAME}_${SNAPSHOT_NAME}" -o "$BACKUP_DIR/${CONTAINER_NAME}_${SNAPSHOT_NAME}.tar.gz"
    lxc image delete "${CONTAINER_NAME}_${SNAPSHOT_NAME}" # Delete temporary image

done

echo "Backup finished at $(date)"
    

Save this script as /usr/local/bin/lxd-backup.sh and make it executable:

sudo nano /usr/local/bin/lxd-backup.sh
sudo chmod +x /usr/local/bin/lxd-backup.sh
    

3. Setting Up Cron for Automatic Execution

Schedule the script to run daily using Cron:

sudo crontab -e
    

Add a line for daily execution, for example, at 3 AM:

0 3 * * * /usr/local/bin/lxd-backup.sh >> /var/log/lxd-backup.log 2>&1
    

4. Where to Store Backups

Storing backups on the same server as the original data is strongly discouraged. In case of hardware failure or server compromise, you will lose both the data and its copies. Use external storage:

• Cloud S3-compatible storage: Amazon S3, DigitalOcean Spaces, Backblaze B2. Use utilities like rclone for synchronization.
• Separate VPS or dedicated server: If you have another server, you can use rsync or scp to transfer backups.
• Network Attached Storage (NAS): If feasible in your infrastructure.

Example of S3 synchronization using rclone:

sudo apt install rclone -y           # Install rclone
rclone config                        # Interactive S3 storage configuration
    

After configuration, add a line for synchronization to the lxd-backup.sh script:

# Add to the end of lxd-backup.sh script
echo "  - Syncing backups to S3..."
rclone sync "$BACKUP_DIR" "s3_remote_name:bucket_name/lxd_backups" --delete-excluded --exclude="*.tmp"
    

5. Updates: Rolling vs. Maintenance Window

• Host Updates: It is recommended to perform these during a "maintenance window" when the load is minimal. Before updating, take a snapshot of the entire VPS (if supported by the provider) or at least an lxd export for all critical containers.

  
  sudo apt update && sudo apt upgrade -y
  sudo reboot                          # Reboot after kernel update
              

• LXD Updates: Since LXD is installed via snap, it updates automatically in the background. You can manually check and update it:

  
  sudo snap refresh lxd                # Update LXD snap package
              

• Container Updates: For each container, it is recommended to configure automatic updates or perform them manually according to your policies.

  
  lxc exec my-web-server bash -- apt update && apt upgrade -y
              

Always test updates on non-critical containers or in a test environment before applying them to production services.

Troubleshooting + FAQ

How to Check LXD and Container Status?

To check the overall status of LXD, use lxc info. To see a list of running containers and their statuses, use lxc list. If a container fails to start, check the logs with lxc monitor --type=lifecycle or lxc info CONTAINER_NAME.

My container is not getting an IP address or has no internet access. What should I do?

Ensure that the lxdbr0 bridge is running and configured correctly. Check lxc network list and ip a on the host. Make sure that IP forwarding is enabled on the host (sysctl net.ipv4.ip_forward should be 1) and that NAT rules for lxdbr0 are present in iptables. If you are using UFW, ensure it is not blocking traffic on lxdbr0. You might need to add rules for lxdbr0 to /etc/ufw/before.rules.

How to forward a port from the host to multiple containers?

You cannot forward the same host port to multiple containers. Each container that needs external access must use a unique host port. For example, Container 1: listen=tcp:0.0.0.0:8080 connect=tcp:10.200.200.X:80, Container 2: listen=tcp:0.0.0.0:8081 connect=tcp:10.200.200.Y:80. Alternatively, use a reverse proxy server (e.g., Nginx or Caddy) on the host to route traffic to the desired containers based on domain name or URL path.

Why use LXD instead of Docker?

LXD is designed to run full system containers that behave like lightweight virtual machines with their own init system (systemd, OpenRC). Docker focuses on containerizing individual applications or microservices. If you need to run several traditional applications, each with its own stack and dependencies, or migrate an existing VM, LXD is often a more suitable choice. Docker is better suited for developing and deploying cloud-native applications.

How to limit resources for a container?

Use LXD profiles. Create or edit a profile with the command lxc profile edit PROFILE_NAME and add limits.cpu, limits.memory, limits.disk parameters to the config section. For example: limits.cpu: "2", limits.memory: "4GB", limits.disk: "50GB". Then apply this profile to the container (lxc profile assign CONTAINER PROFILE_NAME) or launch new containers with it.

What is the minimum suitable VPS configuration?

For running LXD and one or two lightweight containers (e.g., a VPN server and a small website), the minimum configuration might be: 2 vCPU, 2-4 GB RAM, 40-60 GB NVMe SSD. However, for more serious tasks, such as running multiple web applications, databases, or game servers, 4 vCPU, 8 GB RAM, 160-200 GB NVMe SSD is recommended.

What to choose — VPS or dedicated for this task?

For most tasks, such as running personal projects, small SaaS applications, game servers for friends, or several blockchain nodes, a VPS is perfectly sufficient. It is economical and easily scalable. A dedicated server becomes necessary if you encounter VPS performance limitations (e.g., due to "noisy neighbors"), require maximum isolation and resource guarantees, or if you plan to run many containers and services that demand full control over the physical hardware.

How to access container files from the host?

You can use the command lxc file pull CONTAINER/path/to/file /local/path to copy files from the container to the host, or lxc file push /local/path CONTAINER/path/to/file to copy from the host to the container. Also, if you are using dir storage, container files are located in /var/snap/lxd/common/lxd/storage-pools/default/containers/CONTAINER_NAME/rootfs/, but direct editing here is not recommended.

Conclusion and Next Steps

You have successfully set up LXD on your VPS, created and configured containers, ensured their basic security, and set up a backup system. Your VPS is now a powerful, flexible, and efficient platform for hosting various services in isolated environments, which significantly simplifies management and enhances the reliability of your applications.

Where to go next:

1. Resource Monitoring: Install monitoring tools (e.g., Netdata, Prometheus with Grafana) on the host and in key containers to track CPU, RAM, disk, and network usage. This will help identify bottlenecks and optimize performance.
2. Deployment Automation: Explore automation tools such as Ansible, Puppet, or SaltStack. They will allow you to automatically deploy new containers, configure services, and manage configurations, which is especially useful when scaling.
3. Enhanced Network Configuration: For more complex network scenarios, consider using OVN (Open Virtual Network) with LXD to create software-defined networks, or configuring L3 routing to provide containers with public IP addresses if your provider offers them.