DCA Hardened Backup Server for restic — Support & Quick Start

At a glance

Quick start

This is the listing's usage information, verbatim. Every command in it is run by our QA on a freshly launched instance before an image version can publish, so the text and the tested procedure cannot drift apart.

After launch:

1. Connect over SSH as the opc user with the key you supplied at launch:

   ssh opc@PUBLIC_IP

2. On first boot the image generates an instance-unique TLS certificate and a backup user with a random password, proves them against the server, then starts rest-server (HTTPS only, authentication on, private repositories). Check both units:

   sudo systemctl status restic-server-firstboot restic-server

3. Read the generated user, password and certificate fingerprint (root only):

   sudo cat /root/.restic-server_default_credentials

4. Try it with the restic client installed here, replacing PASSWORD with the generated one. restic asks you to choose a repository password; it encrypts your data before it leaves the client, so the server never sees it, and losing it loses the data:

   restic -r rest:https://backup:PASSWORD@127.0.0.1:8000/backup/ --cacert /etc/restic-server/tls/cert.pem init
   restic -r rest:https://backup:PASSWORD@127.0.0.1:8000/backup/ --cacert /etc/restic-server/tls/cert.pem backup /usr/share/doc/restic-server
   restic -r rest:https://backup:PASSWORD@127.0.0.1:8000/backup/ --cacert /etc/restic-server/tls/cert.pem snapshots

5. The server listens on 127.0.0.1:8000 as shipped. To take backups from your hosts, rebind and restart:

   sudo sed -i 's/^REST_SERVER_LISTEN=127.0.0.1:8000$/REST_SERVER_LISTEN=0.0.0.0:8000/' /etc/restic-server/restic-server.env && sudo systemctl restart restic-server

   Each host copies /etc/restic-server/tls/cert.pem (its SAN lists the private IPs) and uses rest:https://USER:PASSWORD@PRIVATE_IP:8000/USER/ with --cacert. For a public IP or DNS name, re-issue the certificate with it:

   sudo /usr/local/sbin/restic-server-cert NAME_OR_IP

   Port 8000 is already permitted in the host firewall. Restrict it in your VCN security list to the CIDRs of the hosts you back up; never expose it to the internet.

6. Give every host its own user; each user reaches only its own /USER/ path (changes apply within 30 seconds, or at once with sudo systemctl reload restic-server):

   sudo htpasswd -B -C 10 /etc/restic-server/htpasswd HOST_NAME

   Ransomware-resistant mode: clients can add backups but never delete or overwrite them, so retention runs here, as the service user, with the repository password:

   sudo sed -i 's/^REST_SERVER_EXTRA_FLAGS=$/REST_SERVER_EXTRA_FLAGS=--append-only/' /etc/restic-server/restic-server.env && sudo systemctl restart restic-server
   sudo -u restic-server /usr/local/bin/restic --no-cache -r /var/lib/restic-server/USER forget --keep-daily 14 --prune

7. Repositories live in /var/lib/restic-server; attach a block volume there before production use. Optional off-site copy to OCI Object Storage over its S3-compatible API: create a bucket and a Customer Secret Key, open a root shell (sudo -i) and run the lines below; restic asks for both repository passwords, and later copy runs send only new snapshots:

   export AWS_ACCESS_KEY_ID=ACCESS_KEY AWS_SECRET_ACCESS_KEY=SECRET_KEY AWS_DEFAULT_REGION=REGION RESTIC_REPOSITORY=s3:https://NAMESPACE.compat.objectstorage.REGION.oraclecloud.com/BUCKET/USER
   runuser -u restic-server -- /usr/local/bin/restic --no-cache init --from-repo /var/lib/restic-server/USER --copy-chunker-params
   runuser -u restic-server -- /usr/local/bin/restic --no-cache copy --from-repo /var/lib/restic-server/USER

The image is CVE-patched at build time. Apply ongoing operating system updates with:

sudo dnf -y update

What the image provides

• rest-server 0.14.0 and restic 0.19.1 (both BSD-2-Clause), compiled from each release's GPG-signed source with a current Go toolchain (1.26.9). Dependencies that carried published HIGH or CRITICAL vulnerabilities are raised to their fixed releases, and every build is checked against the restic release key and reproduced bit for bit. rest-server runs as a dedicated unprivileged systemd service with no capabilities and write access only to its repository directory.
• Authentication from the first boot: a backup user with a password generated uniquely for this instance, proven against the running server and surfaced to the operator over SSH. There is never a shared default credential, and one command adds a user per host.
• Private repositories: each user can reach only its own repository path.
• Encryption in transit: HTTPS only (TLS 1.2 or later) with an instance-unique certificate generated at first boot and its fingerprint recorded for client verification. One command re-issues it for a public IP address or DNS name.
• Ransomware-resistant mode on request: one documented command switches the server to append-only, where clients can add backups but never delete or overwrite them, and retention runs on the server.
• Optional off-site copies: documented steps copy repositories to OCI Object Storage through its S3-compatible API, using the restic client already on the image.
• Safe-by-default network posture: the server listens on loopback until you expose it with one documented command, and Prometheus metrics are off. Security hardening is aligned to the Oracle Cloud Marketplace image standards: SELinux enforcing, a host firewall that denies by default and permits only SSH and port 8000, no account with a usable password, and the image fully patched at build time.

Still stuck?

Email support@dcassociatesgroup.com (response within 1 business day) or use the contact form. Include the listing name, your OCI region, the instance OCID and the output of sudo journalctl -u <service> -n 100 for the unit named in the quick start.