On my previous post, Hello DaBrain, i talked about the evolution of my HomeLab and detailed the latest version, a K3s cluster plus two storage Raspberry Pi’s, but there was an open topic. How to handle backups?

I wanted a solution to put on a Raspberry Pi on an off-site location to backup important data from my RAID10 array like Nextcloud and Vaultwarden data, K3s tokens and database and more just in case something bad happened to my apartment.

Probably, the most simple and quick solution would be creating a cronjob running a rsync command to synchronize the folders (, and had a solution like that on my cluster v1). That worked fine but was not perfect. It didn’t had a way to manage/track changes to a file, so if i wanted to restore a previous version i would need to do it before the cronjob was executed again. So started to investigate a little, until i found Minarca.

Meet Minarca

Minarca is a open-source data backup solution that uses a reverse incremental differential backup technique and mirrors the source directory structure, making it easy to recover data with or without the application (and many more features) with a simple and intuitive UI.

Everything looked perfect until i found out that there was no support for arm64 (Raspberry’s CPU architecture) 😢. I was really interested on the solution, so took the challenge and tried to create a arm64 version for myself.

Understand Minarca’s architecture

The first thing before starting to creating or changing any code was to understand how Minarca works, at least the basics. Minarca is split into two main components, the client and the server, both written in python.

The client is an executable that is installed on the machine that contains the files to be backed up (in the end it’s a cronjob that will invoke a Minarca command that will then use rdiff-backup to backup new files and update existing ones on the server).

The server can be an executable or a container running and is responsible to manage users, storage locations, quotas, providing nice dashboards and more.

Me being me didn’t even thought about creating just the executable, but instead creating a OCI image to run it on a container runtime (Docker, Podman, containerd, runc, etc). Also because if i succeeded i could easily extract the .deb file and then use it to install directly on the machine.

With the basics understood, it was time to start digging on how was Minarca built (CI/CD wise) and what makes it tied to amd64 architecture.

The first part was simple, it was a matter of checking the .gitlab-ci.yml file and check for the tox commands that were responsible to build, test and package the software. The second part was the challenging one, finding on the code what made Minarca tied to amd64.

After some time, found out that there is a architecture='amd64' on the minarca.spec that controls the architecture to which the end executable will be created for. Challenge complete, i thought, until finding out that the rdiff-backup tool is also a custom one with some patches 😅.

Build a custom version for arm

With all the questions answered it was time to create the arm64 version of Minarca. And nothing better to start than with the client. Created a container to do all the development (because could discard all the work easily in case of errors), cloned the official repo, used sed to replace the magic string and run the tox commands. After some days had the client package created and working, awesome 😎.

Time to move to the server, should be simple too, just follow the same approach as for the client, right? NO. The steps to build the server revealed to be nerve-racking. The rdiff-backup part was expected and worked fine but had a couple of tests that were failing on the docker container but that were ok when running everything on bare-metal, the same as installing some packages failing with the error

dpkg: error processing archive /tmp/apt-dpkg-install-8t4Xzo/44-minarca-server.deb (--unpack): unable to move aside './opt/minarca-server/minarca-server' to install new version: Invalid cross-device link
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

Time to investigate 🔎.

After some days and some hairs pulled out, found out that the default image builder configuration was not enough to compile, install and run Minarca server. In part due to Minarca using linux namespaces to separate user’s data. The solution? Creating a custom image builder following the steps mentioned on this stackoverflow thread. Once this was in place, everything worked fine 🎉

With everything figured out, it was time to move everything to GutHub Actions (probably the easiest step fso far). You can check all the source code for the minarca-client here and for minarca-server here.

Deploy

With both components created, it was time to deploy/install them.

If we check the diagram from the previous blog post, the goal was to have the server running on the Vector machine and backup the files from LeMal (and others). Meaning deploying minarca-server with Docker Compose on Vector and installing the executable on LeMal. Let’s check some code.

docker-compose.yml

services:
  minarca-server:
    image: joaoppcastelo/minarca-server-arm64:v1.0.0
    ports:
      - "8080:8080"
      - "2222:22"
    volumes:
      # Location of the backups
      - ./backups:/backups
      # Configuration file and local database
      - ./conf:/etc/minarca
      # Application logs
      - ./logs:/var/log/minarca
    restart: always
    privileged: true
    environment:
      MINARCA_BRAND_HEADER_NAME: Minarca Server
      # Define the URL to be used by users to connect to this container port 8080 running the webserver.
      #MINARCA_EXTERNAL_URL: https://minarca.mycompagny.com
      # Define the hostname and ip address to be used by Minarca Agent to connect to this container on port 2222 running SSH Server.
      MINARCA_MINARCA_REMOTE_HOST: localhost:2222

And for the clients, it’s as simple as

# Download the .deb package from GitHub
curl -L -o minarca-client-arm64.deb https://github.com/JoaoPPCastelo/minarca-client-arm64/releases/download/v1.0.1/minarca-client_6.1.0a3_arm64.deb

# Install the .deb package on your system
apt install -y ./minarca-client-arm64.deb

# Check the installation
minarca --version

After this, it’s just following the Minarca commands to connect to the server and define which folders to backup. You can check the official documentation here.

The future

This adventure was more a challenge to see if could make Minarca work on arm64 since i was really interested on it, and seems it was a successful adventure.

But it doesn’t stop here. Want to improve and explore more the GitHub Actions and also keep up with any new versions of Minarca to benefit from the amazing work Patrik has been doing.

Reference

• Official Minarca’s Homepage
• Official Minarca’s documentation
• Official Minarca’s client repo
• Official Minarca’s server repo
• minarca-client-arm64
• minarca-server-arm64

Credits

Photo by Linus Mimietz on Unsplash