sdub

You’d have to raise an issue with the container itself. I just maintain the unraid template for the CA store. GitHubGitHub - borgmatic-collective/docker-borgmatic: Borgmatic...Borgmatic in Docker. Contribute to borgmatic-collective/docker-borgmatic development by creating an account on GitHub.

Just make sure you have the keypair set up so you can ssh from the server to the pi, without a password then put - path: ssh://user@backupserver/path/to/repo This is described in the borgmatic reference https://torsion.org/borgmatic/docs/reference/configuration/

The crontab looks correct. The borgmatic config yaml looks OK but you should run it through the validator to be sure: usage: borgmatic config validate [-s] [-h] Validate borgmatic configuration files specified with --config (see borgmatic --help) config validate arguments: -s, --show Show the validated configuration after all include merging has occurred -h, --help Show this help message and exit Can you open a shell into the docker container and run the borgmatic command directly? docker exec -it borgmatic /bin/bash borgmatic prune create -v 1 --stats What do you see on the console? 9 times out of 10 when a backup fails to start, it's because there was a canceled backup and a stale lockfile exists. If you run ps -a and don't see any borg commands running, you can remove the lock with borg break-lock /mnt/borg-repository Either way, it's probably a good idea to write logfiles. borgmatic prune create -v 1 --stats --log-file /mnt/borg-repository/logs/backup.log Furthermore, you might find the logrotate command to keep the last 3 or 4 log files so it's not overwritten each time. Reply here with your console or log output from running the borgmatic command manually. Maybe with -v 2 for more verbose output.

Sorry for the delayed response @gamerayers…. Borg uses deduplication, which means it only stores unique data blocks. With your retention settings (keep_daily: 2, keep_weekly: 1), you won't need 6TB total storage. Here's why: - First backup: ~2TB (full dataset) - Second daily backup: Only stores blocks that changed since yesterday (maybe 1-50GB depending on your photo activity) - Weekly backup: Only stores unique blocks not already in the repo So you're looking at roughly 2TB + incremental changes, not 4-6TB. The exact overhead depends on how much your Immich data changes daily. Your config file looks reasonable to me but I think you’d want to keep more historical backups since it’s so space efficient. The way your config file is set up, it will try to perform both backups sequentially every time. You’d be better off with separate config files with different cron schedules. There are tricks you can do with includes and defining variables in YAML to make it easier to keep the settings in sync. The checks can be more sporadic… maybe monthly. Borgmatic now has some clever features that let you do partial checks on every backup. I have a very large repo and the checks can take a day or more if not broken up. https://torsion.org/borgmatic/docs/how-to/deal-with-very-large-backups/

The Unraid template that I maintain simply installs the latest Borgmatic container. Ensure that your repository in Unraid Docker is pointing to: ghcr.io/borgmatic-collective/borgmatic:latest To understand what version of Borg and Borgmatic will be installed, you can look at the Dockerfile on Github. There's a line under the RUN section that executes when the container is built by Docker when Unraid pulls a new version: python3 -m pip install -Ur requirements.txt If you look in this requirements.txt file, you will see the versions that will be installed: borgbackup==1.4.1 borgmatic[apprise]==2.0.5 These are the latest stable versions. Borg 2.0 is still in development and shouldn't be used in production. if these don't match your installed version, make sure you're pointing to the right repository.

Thanks. Done. If you try to re-create the container, it will used a cached copy of the template. You'll either need to add this manually, or follow these steps: Delete Borgmatic Docker container (make note of current settings) Go to /boot/config/plugins/dockerMan/templates-user/ via SSH or File Manager. Delete the file "my-borgmatic.xml" Restart Unraid’s Docker Service (Settings > Docker > Stop, then Start). Install the app again from Community Applications using the settings you retained from step 1.

These are really borg-specific questions not specific to UnRaid, so I'd recommend you consult those support resources: https://docs.borgbase.com/restore/borg/ https://docs.borgbase.com/restore/borg/borgmatic $ borgmatic extract \ --archive server-2020-04-01 \ --path mnt/catpics --destination /mnt/new-directory Having said that, I'll take a stab at answering. SSH Keys are really needed for accessing remote resources (like backing up over the network or internet to a remote server). If your backups are all local, it's probably not relevant. The Borg passphrase is not related to the SSH key. The Borg passphrase is all about how your data is encrypted at rest, and the SSH keys have to do with how your data is encrypted in transit. See the links above for details on how to restore data from the command line or from other utilities. Similar to my comment above, if you want to extract data the Borg passphrase will be necessary to decrypt the data, whether it's to the local machine or another machine on your network.

You should create a top level support request I the forums. I have never seen anything like this, and I think this docker container is a symptom not the cause

Not sure what happened but I contacted Squid and Borgmatic is back in CA.

Hi, I'm the template manager for the borgmatic backup docker application in the Unraid CA appstore. It appears that with the 6.12 release, the application was removed for some reason. Perhaps I missed some communication from @Squid regarding something I needed to do with the metadata to maintain compatibility Can you help me understand how to get it reinstated? Here is the support thread... Here is the github template repo... https://github.com/Sdub76/unraid_docker_templates Thanks

I’ll take a look this weekend and see why it doesn’t show in CA anymore. I haven’t upgraded to 7 and my existing install is working fine. Creating a plugin is probably beyond what i can pull off at this time… I prefer the docker container since that’s what is officially supported by Borgmatic. All I manage is the CA template that points to the official container.

I am not at my server right now but I can say that my backups are still working and I haven’t touched the config in months. the Unicode error makes me wonder… did you possibly edit your config file in windows such that it has a Windows text file format instead of UNIX?

No I don’t. I use the database backup functions for things like MariaDB and Postgres and the built-in database backup function for file based databases like Plex. For everything else the risk is realistically minimal. Especially with scheduled backups and a multitude of retained versions. In the off-chance the daily backup happens to be bad, there are other daily, weekly, monthly Archives I can draw from. Losing a day or two of data isn’t a big concern of mine.

Looks like the root issue is in that '/root/.cache/borg' folder. If you open a shell into borg and browse to that folder, does everyhing appear normal? Could be that folder mapping is screwed up in your docker config.

you can also specify the config file with the borgmatic -c /path/to/config syntax. I personally have a local.yaml and remote.yaml that both include a common.yaml for common options. I call the local and remote backups through separate lines in my crontab

Your repo should be “/mnt/borg-repository” not “/mnt/user/disks/easystore264D”. You have mounted “/mnt/user” as a read-only path, so you can’t write to the repo via that path.

It looks to me like maybe you are mounting the share to Borgmatic as read-only… not that it’s read only in the host filesystem. What’s your Borgmatic docker config look like?

To reduce data transmission, Borg requires the borg binary to be present on both the local machine and the remote machine when performing remote backups. That way the remote machine can do the work of comparing what's changed from the cache. If you don't want to (or can't) install borg to the host OS, you can run nold360's borgserver container on the remote machine. This image has just the plain "borg" binary and an SSH server to allow it to act as a borg "target". No borgmatic, but allows you to connect and perform a backup "to" that remotely running docker container. If you were running a backup scheme where computer A backs up to computer B and vice versa, an ideal scenario would be just having the 2 "borgmatic" docker containers talk to each other. Unfortunately, the official borgmatic container lacks an SSH server so you can't. It's been requested to add SSH server support but they've declined to do so to keep the image simple. This CA application uses the "official" borgmatic container published by the borgmatic team. The alternative to using the "borgserver" container in Unraid is to use the Nerdpack to install borg directly to the host Unraid OS, since it's already running the requred SSH server. If you were just using vanilla borg and not borgmatic, you certainly could run the "borgserver" container on both the local and remote systems and need nothing else. Hope that clarifies.

OK, @Greygoose and @stridemat, I updated the CA template to point to a static location for the borgmatic icon. Future pulls should get this, but I'm not sure if it will automatically update for you. To manually fix, go to advanced view in the Borgmatic docker container config. Change "Icon URL" to https://raw.githubusercontent.com/Sdub76/unraid_docker_templates/main/images/borgmatic.png This is a static copy that I have in the CA repo, so it shouldn't change unless github changes it's static URLs.

I’m afraid I’ve never gotten this to work in the docker container. I’ve tried passing the fuse device in, but I can’t access the share externally. I may have the permissions wrong or maybe it’s something else. what I’ve always done is use this image to create the backup image then use the Borgmatic binary on the host system (either Unraid or some other host OS that can access the borg repo on the LAN) to browse and extract the files I need. Borg and llfuse can be installed from the Nerdpack in Unraid. if someone else has been able to expose a mounted repo from outside the docker container I’d love to hear how.

Sorry I missed this issue. I’ll take a look and get back to you… for most issues it’s more effective to ask in the Borgmatic GitHub support page. last year they moved the Borgmatic repo from b3vis’s repo to the main “Borgmatic-collective” repo. I updated the template but maybe something else changed. that specific error at first glance looks like the link to the icon just changed. Is it causing Borgmatic to not update/work for you?

I haven’t updated the CA container in some time just because it hasn’t been necessary. The docker container it pulls from is still very actively developed and widely used, so yes it’s still active. If needed I’ll update the CA template.

ps -ax

Borg creates a lock to make sure it has exclusive access to the backup archive and cache to avoid corruption. When a backup gets interrupted, that lock is sometimes left in place, blocking subsequent backups. Whenever you see an error about not being able to acquire a lock, the first thing you need to do is break the lock if you are sure that no borg process is running against that repo. From inside the borg container (docker exec -it borgmatic /bin/sh), run following command and try again. borg break-lock /mnt/borg-repository

It's going to be hard to help debug this without some specifics from the error logs. Does it simply not run, or does it occasionally fail? If it fails, how does it fail? If the folks on this thread can't help, maybe a support ticket over at Borgmatic docker github could help. Remember I only maintain the docker template in the CA Appstore. @witten is the actual developer of the docker image. The automatic docker updates in Unraid are handled by the CA APPLICATION AUTO UPDATE plugin. As long as your repository is set to "ghcr.io/borgmatic-collective/borgmatic" it should work. Note that this location changed somewhat recently, but shouldn't explain why "auto-update" vs "forced update" behaves differently. Maybe consult that support thread for help.