Minarca on Ubuntu 24.04 on Azure User Guide

Overview

Minarca is a free, self-hosted, open-source data backup platform. It centralises backups from your Linux, Windows and macOS machines onto one server and gives you a single web interface to browse every repository, watch usage and quotas, and restore files or whole folders from any point in the retention history. Client machines run the Minarca agent, register with the server over SSH, and stream their data with rdiff-backup so each run stores only the blocks that changed and keeps efficient, browsable incremental history.

The cloudimg image installs the pinned Minarca server 6.2.5 from the vendor's signed APT repository, runs it under systemd, and fronts the web UI with an nginx reverse proxy that terminates HTTPS. The Minarca server binds only to loopback; the web UI requires an admin password generated uniquely on the first boot of every VM (the upstream default admin/admin123 is permanently retired); and backups arrive over SSH into a per-user repository tree. Backed by 24/7 cloudimg support.

What is included:

• Minarca server 6.2.5 running as the minarca-server systemd service (rdiffweb web UI + REST API)
• The web UI bound to loopback 127.0.0.1:8080, never exposed directly
• An nginx reverse proxy terminating TLS on :443 with a per-VM self-signed certificate, and :80 redirecting to HTTPS
• A backup-receiving endpoint on SSH :22 (the minarca user, restricted to rdiff-backup by a forced-command shell)
• A unique admin password generated on first boot, so no shared credential ships in the image
• An unauthenticated /healthz endpoint for Azure Load Balancer health probes
• 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a comfortable starting point; add disk capacity for the backups you intend to store. NSG inbound: allow 22/tcp (used for both administrative SSH and for receiving client backups), 443/tcp for the web UI, and optionally 80/tcp, which only redirects to HTTPS. The UI is served over HTTPS with a self-signed per-VM certificate; for production, put your own domain and a CA-signed certificate or a reverse proxy in front of it (see Maintenance).

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Minarca by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and HTTPS (443). Then Review + create -> Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name minarca \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

az vm open-port --resource-group <your-rg> --name minarca --port 443 --priority 1010

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

systemctl is-active minarca-server nginx

Both report active. The Minarca server serves the web UI on the loopback connector 127.0.0.1:8080 only; nginx fronts it on port 443 with TLS and redirects port 80 to HTTPS. Backups are received by the system SSH server on port 22. Because the web server binds loopback, the only way into the UI is through the nginx TLS proxy.

Step 5 - Retrieve your admin password

Minarca protects its web UI with a login. A unique admin password is generated on the first boot of your VM and written to a root-only file:

sudo cat /root/minarca-credentials.txt

This file contains MINARCA_URL, the address to open in a browser, MINARCA_ADMIN_USER (admin), MINARCA_ADMIN_PASSWORD, the generated login password, and MINARCA_BACKUP_HOST, the address your backup clients connect to. The password is enforced through the per-VM options file /etc/minarca/conf.d/10-cloudimg.conf (mode 0640), so no shared password ships in the image. Store it somewhere safe.

Step 6 - Confirm the health endpoint

nginx serves an unauthenticated health endpoint for load balancers and probes:

curl -sk https://localhost/healthz

It returns ok. This endpoint never requires authentication, so it is safe for an Azure Load Balancer health probe. A plain request to port 80 returns 301 and redirects to HTTPS.

Step 7 - Confirm authentication is enforced

Because a password is set on first boot, an unauthenticated request to the web API returns HTTP 401, and the upstream default admin/admin123 no longer works. The following proves an unauthenticated call is rejected, the old default is dead, and the per-VM password authenticates:

echo "unauth: $(curl -sk -o /dev/null -w '%{http_code}' https://localhost/api/)"
echo "default admin123: $(curl -sk -o /dev/null -w '%{http_code}' -u admin:admin123 https://localhost/api/)"
PW=$(sudo grep '^MINARCA_ADMIN_PASSWORD=' /root/minarca-credentials.txt | cut -d= -f2-)
echo "per-VM password: $(curl -sk -o /dev/null -w '%{http_code}' -u "admin:$PW" https://localhost/api/)"

It prints unauth: 401, default admin123: 401, then per-VM password: 200. Only the per-VM password reaches the API.

Step 8 - Sign in to the web UI

Browse to https://<vm-public-ip>/. Because the certificate is self-signed and unique to your VM, your browser shows a certificate warning the first time; accept it to continue (or install the certificate from /etc/nginx/tls/minarca.crt to trust it). Enter the user name admin and the password from Step 5, then select Sign in.

Step 9 - The repositories dashboard

After signing in, Minarca opens on the Repositories view. A storage usage summary shows how much of the backup volume is used, and each backup source appears as a repository tile with the time of its last backup. From here you open a repository to browse its contents, and the Admin area gives you user and system management.

Step 10 - Browse and restore your backups

Open a repository to browse its file tree. Minarca lists every backed-up folder with its size and how many stored versions it has, and you can drill into any folder, pick a version from history, and restore individual files or whole directories. The Files, Settings, Graphs, Snapshot Changes and Logs tabs give you the full view of the repository, its retention and its activity.

Step 11 - Manage users

The Admin area lets you add users, assign roles (admin, maintainer or user), set a per-user root directory and storage quota, and review sessions and activity. Each user gets their own isolated repository tree, so you can host backups for many machines and people on one server.

Step 12 - Back up a client and verify a restore round trip

To protect a machine, install the Minarca client on it and point it at your server. The client uploads its SSH key through the web UI and then streams backups over SSH into its own repository:

# On the client machine (Linux example):
minarca configure --remoteurl https://<vm-public-ip> --username admin --name my-workstation
minarca backup

The image also ships a self-test that proves the full path end to end - the web UI requires the per-VM password, and a real backup is written and restored through the same SSH endpoint (minarca-shell -> rdiff-backup) that clients use:

sudo /opt/minarca-cloudimg/minarca-selftest.sh

It prints OK: unauth=401 wrong-pw=401 authed=200; rdiff-backup round-trip via minarca SSH endpoint matched. Received backups live under /backups/, one repository per client.

Maintenance

• Password: the admin password is set on first boot as an {SSHA} hash in /etc/minarca/conf.d/10-cloudimg.conf. With it set, the password cannot be changed from the web UI; to rotate it, generate a new {SSHA} value, update that file (as root), and run sudo systemctl restart minarca-server.
• Adding users and clients: create users in the Admin area, then register each client with minarca configure. Every client machine uploads its own SSH key and streams to its own repository under /backups/.
• Backup storage: received backups are stored on the VM under /backups/. Grow the OS disk, or attach and mount a larger data disk there, to scale capacity; rdiff-backup keeps efficient incremental history.
• Retention: set a "remove older than" policy per repository under its Settings tab so old increments are pruned automatically.
• TLS: the UI is served over HTTPS with a self-signed per-VM certificate at /etc/nginx/tls/minarca.crt. For production, replace it with a CA-signed certificate for your own domain, or place a reverse proxy in front.
• Upgrades: Minarca is installed from the vendor's signed APT repository; to upgrade, sudo apt-get update && sudo apt-get install --only-upgrade minarca-server and restart the service. Your users, repositories and history are preserved in /etc/minarca and /backups.
• Security patches: unattended-upgrades remains enabled so the OS continues to receive security updates automatically.

Support

cloudimg provides 24/7 expert support for this image. Contact support@cloudimg.co.uk.