Minarca

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B2s (2 vCPU / 4 GiB RAM) is a comfortable starting size. Add disk capacity for the backups you intend to store.

Configure the network security group (NSG) to allow inbound 22/tcp, which serves both administrative SSH and incoming client backups, and 443/tcp for the web UI. Optionally allow 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 SecureAnyCloud, and select Create.

On the Basics tab, 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).

Select Review + create, then Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:minarca-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name minarca \
  --image sac1647283583153:minarca-ubuntu-24-04:default:latest \
  --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

Connect to the VM over SSH:

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

Check that the services are active:

systemctl is-active minarca-server nginx

Both services 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. The system SSH server receives backups on port 22.

Because the web server binds to 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. The first boot of your VM generates a unique admin password and writes it to a root-only file. Read the file with sudo:

sudo cat /root/minarca-credentials.txt

The file contains the following values:

• MINARCA_URL, the address to open in a browser
• MINARCA_ADMIN_USER (admin)
• MINARCA_ADMIN_PASSWORD, the generated login password
• MINARCA_BACKUP_HOST, the address your backup clients connect to

The per-VM options file /etc/minarca/conf.d/10-sac.conf (mode 0640) enforces the password, so no shared password ships in the image. Store the password somewhere safe.

Step 6 - Confirm the health endpoint

nginx serves an unauthenticated health endpoint for load balancers and probes. Request it from the VM:

curl -sk https://localhost/healthz

The endpoint returns ok. It 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 first boot sets a password, an unauthenticated request to the web API returns HTTP 401, and the upstream default admin/admin123 no longer works. Run the following commands to confirm that 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/)"

The output shows 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>/. The certificate is self-signed and unique to your VM, so your browser shows a certificate warning the first time. Accept the warning 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 you sign in, Minarca opens on the Repositories view. A storage usage summary shows how much of the backup volume is used. Each backup source appears as a repository tile with the time of its last backup.

From here, open a repository to browse its contents. The Admin area provides 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 the number of stored versions. Drill into any folder, pick a version from the 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

In the Admin area, 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 the client at your server. The client uploads its SSH key through the web UI, 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 the test writes and restores a real backup through the same SSH endpoint (minarca-shell -> rdiff-backup) that clients use. Run it:

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

The test 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. First boot sets the admin password as an {SSHA} hash in /etc/minarca/conf.d/10-sac.conf. While it is set, you cannot change the password 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/. To scale capacity, grow the OS disk, or attach and mount a larger data disk there. rdiff-backup keeps an 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, run sudo apt-get update && sudo apt-get install --only-upgrade minarca-server, then restart the service. Your users, repositories and history are preserved in /etc/minarca and /backups.
• Security patches. Unattended upgrades stay enabled, so the OS keeps receiving security updates automatically.

Support

SecureAnyCloud provides 24/7 expert support for this image. For questions or help with your deployment, contact sales@secureanycloud.com.

Deploy on Azure

Launch Minarca on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com