Skip to content
View in the app

A better way to browse. Learn more.

Unraid

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

[Support] borgmatic

Featured Replies

  • Author

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. 

Edited by sdub

  • Replies 277
  • Views 90.5k
  • Created
  • Last Reply

Top Posters In This Topic

Most Popular Posts

  • Here are example crontab and config files with some descriptions.  Both files should be placed in the appdata/borgmatic/config folder   Example crontab: Twice Daily backups @ 1a, 1p

  • FIXED: CRON schedule not running   Ok sorted it.   I recreated the crontab.txt file in the docker console using vi.   Now the cron is working. It must have been a permis

  • Rick_Sanchez
    Rick_Sanchez

    I’m going to try and sudo nano the crontab.txt and see if that fixes the /bin/ash error I’m getting. I just read the comments above.   Update: I've tried using the unraid terminal to nano th

Posted Images

  • Author

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

  • 3 weeks later...

I don't really know where to start as I think there are happening a few things that shoudn't happen in a few layers. But as borgmatic in unraid is the first layer, Ill start here.

 

Borgmatic worked fine for over a year. All of a sudden, it stopped. With some investigation, I found the following in the logs:

 

Quote

OSError: [Errno 28] No space left on device

 

I checked every "space" I could imagine. I upgraded the hetzner remote space, I double checked but everything locally and all seemed fine.

 

Concerning to me: at the same time, the whole unraid started to act weird. GUI was unresponsive, I got weird, cryptic error messages from time to time, other docker containers stopped repsonding etc etc.

 

After fiddeling around, I upgraded my RAM form 12 GB to 16 GB and everything worked great again. So I guess the "device" with no space left was my RAM? Alright, fine. Everything went back to normal.

 

But sure enough, after a few weeks with more stuff to backup, it broke again. But now I can't just extend my RAM as I maxed out what my system can handle.

 

Whats weird to me: after a fresh restart of unraid, everything is working great. When I start a backup or prune the RAM usage of docker goes up to 55%, borg fails, I stop the whole container and instead of the 55% just beeing freed again, this amount just stays allocated but instead of beeing part of "docker" usage, it turns into "system" usage. A quick look at TOP I can't find any process allocating that much memory. This is the top line of top with all processes allocating <2.5% memory:

 

Quote

MiB Mem :  15925.6 total,   1118.5 free,   9673.3 used,  13310.9 buff/cache     
MiB Swap:      0.0 total,      0.0 free,      0.0 used.   6252.3 avail Mem

 

And the worst of all: unraid starts acting weird again. In the Main Tab the Devices disappear and apear again once a second. Temp value is just "*", Boot device is an empty listing. Connecting to shares by SMB isn't possible anymore and the list goes on and on. Only a restart brings everything back to normal (until the next borg run).

 

So my issue consists of two parts:

 

1. How do I get borgmatic working again without the prossibility to upgrade the memory again?

2. Any issue of a container in docker shouldn't affact the system in that way, should it? I seems to me, whatever goes wrong, should be handled more gracefully by the system. Just because a container goes rogue (espacially as "not enough RAM" is a predicatable error), It shouldn't drag the whole system down? (I know how docker is not a VM and more tied to the system by using the same processes... but still?)

 

As I said, I don't really know where to start. Any help would be appreciated. Where should I start? What info is necessary?

 

Thanks a lot!

Do you use Snapshots by Hetzner?

Please check this Storage and the completed Storage, Data, Snapshots, ...

Maybe you must removed Snapshots manually to more free Space.

28 minutes ago, Revan335 said:

Do you use Snapshots by Hetzner?

Please check this Storage and the completed Storage, Data, Snapshots, ...

Maybe you must removed Snapshots manually to more free Space.

No snapshots used and 4,5TB free space

  • Author

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 

I think I found the issue here.

 

In your first post you mention the following:

 

Quote

It is recommended that your Borg repo and cache be located on a drive outside of your array (via unassigned devices plugin)

 

I guess that's why by default the "Borg Repo (Backup Destination):" is set to "/mnt/disks/borg_backup/cache/" in the blueprint, which I did not change. But if the "unassigned devices plugin" isn't activated, this path does not lead to a device, therefore the system uses the root path (?). As I don't have other devices attached (and no real way to do this), I don't have this plugin activated.

 

When checking the settings I always assumed that "/mnt/disks/" just is a path to write to one of the disks in the array without specifying one. Which its not. And that is kinda confusing to me.

 

This setup worked okay for 1,5 years and 5TB of files, but at some point the cache filled the root path up until there was no space left and thats why unraid started acting so weird.

 

I changed the path to the cache drive and I'm running a prune command right now. We will see how that turns out, but I'm pretty confident that this was the issue. So far, it looks much better.

  • 4 weeks later...

Is it possible to add the mapping '/mnt/user/appdata/borgmatic/state':'/root/.local/state/borgmatic' to the unraid template?

 

This would ensure that the frequency of consistency checks can be maintained even across a container update. I have done this locally but might be worth adding to the master template.

 

See Borgmatic Volumes

  • 4 weeks later...

Hi,

 

Got borgmatic installed (cache and repo on /mnt/disks/...), initiated a repo and created a test archive, now mount throws me an error:

 

borgmatic mount --archive latest --mount-point /dev/fuse

 

image.png.87b8dac0fcde9eaa8648b9bc0925d781.png

 

Did not change the Docker template and default is

image.png.2fa325c628053bd79310aad37bbd7351.png

 

I have read all posts here but I am not getting it.  Please help a noob. What do I need to change to fix this?

 

 

 

Edited by Fred-Unraid

Ok, I figured it out, I just have to provide a container path as mount point. So I used this command:

 

borgmatic mount --archive latest --mount-point /media/restore

 

I can now navigate to this directory in the container terminal and look through the files I had backed up. Nice, but how do I copy a file to a destination outside the container? I cant copy to anything on /mnt/user because that's a read only path.

 

Wouldn't it be easier and more convenient to mount the archive to a path outside the container? So I could use the Unraid GUI to navigate the files and copy/restore what I need.

 

I know I am lacking fundamental knowledge how this works and would highly appreciate if someone explained what I am doing wrong here.

 

Thanks,

Fred

@Fred-Unraid, you need to map "/media/restore" into the unraid filesystem. Edit the borgmatic docker template and add a new path mapping (scroll to the bottom of the template for the Add Path link). For example, set the Host Path to say "/mnt/borg_restore", the Container Path to "/media/restore" and Access Mode to "read/write - shared". Press Save then Apply to restart the docker. You may need to make the "/mnt/borg_restore" directory read/writeable to all so the docker container can write to it (chmod 777 /mnt/borg_restore from unraid cli). Hope that helps.

On 1/19/2022 at 12:03 AM, sdub said:

 

You need to manually initialize the repo as described here:

https://torsion.org/borgmatic/docs/how-to/set-up-backups/#initialization

 

You can either follow my configuration guide in the first post in this thread or go right to the source for help with the config files:

https://torsion.org/borgmatic/docs/reference/configuration/

 

I think Borg is a great solution for any backup needs.  I currently have it running backups:

1.  From my Unraid array to a local backup drive

2. From my Unraid array to a remote Unraid server

3. From a windows PC running the Docker Borgmatic image

4. From a windows PC running borgmatic under WSL2

5. From a Macbook running Vorta

 

All of them are running very reliably.  Unless you're using Vorta, you have to be willing to mess with text-based config files, but it's really not that complicated.

 

I've gotten a Vorta docker container to run under Unraid, but I'm hesitant to publish it to the CA appstore since I don't actively use it.  I'm not really a developer, just an enthusiastic user!

Hello!

I am looking to backup my UnRaid shares to an external HDD. 

What do I need ssh keys for? 

If i want to encrypt my backup, is it ok if i use a pass-phrase as opposed to a ssh key?
What are the steps to restore a backup? If i want to test whether the backup is working?

If i want to extract an encrypted repository - (say from an external Hdd which i used for backup) in another host machine, (say my windows or mac laptop) should i use the same pass-phrase which i used while taking the backup? 

 

Edited by NASBuilder

On 3/8/2025 at 4:54 PM, PeteBa said:

@Fred-Unraid, you need to map "/media/restore" into the unraid filesystem. Edit the borgmatic docker template and add a new path mapping (scroll to the bottom of the template for the Add Path link). For example, set the Host Path to say "/mnt/borg_restore", the Container Path to "/media/restore" and Access Mode to "read/write - shared". Press Save then Apply to restart the docker. You may need to make the "/mnt/borg_restore" directory read/writeable to all so the docker container can write to it (chmod 777 /mnt/borg_restore from unraid cli). Hope that helps.

 

Thanks @PeteBa, I have been playing around with the template and added another path to map a mount point on Unraid,  but hadn't set Access Mode to "read/write -shared" nor changed the permissions with chmod. Now I am happily mounting away 🙂  . Appreciate your help!

  • Author
21 hours ago, NASBuilder said:

Hello!

I am looking to backup my UnRaid shares to an external HDD. 

What do I need ssh keys for? 

If i want to encrypt my backup, is it ok if i use a pass-phrase as opposed to a ssh key?
What are the steps to restore a backup? If i want to test whether the backup is working?

If i want to extract an encrypted repository - (say from an external Hdd which i used for backup) in another host machine, (say my windows or mac laptop) should i use the same pass-phrase which i used while taking the backup? 

 

  

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.
  • Author
On 2/7/2025 at 12:04 PM, PeteBa said:

Is it possible to add the mapping '/mnt/user/appdata/borgmatic/state':'/root/.local/state/borgmatic' to the unraid template?

 

This would ensure that the frequency of consistency checks can be maintained even across a container update. I have done this locally but might be worth adding to the master template.

 

See Borgmatic Volumes

 

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:

  1. Delete Borgmatic Docker container (make note of current settings)
  2. Go to /boot/config/plugins/dockerMan/templates-user/ via SSH or File Manager.
  3. Delete the file "my-borgmatic.xml"
  4. Restart Unraid’s Docker Service (Settings > Docker > Stop, then Start).
  5. Install the app again from Community Applications using the settings you retained from step 1.
  • 1 month later...

Is this container updated to the latest borg?

  • Author
1 hour ago, greygoose1 said:

Is this container updated to the latest borg?

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.

 

 

Edited by sdub

Thanks for the super fast reply

 

Docker is set to

ghcr.io/borgmatic-collective/borgmatic

 

I will change to

ghcr.io/borgmatic-collective/borgmatic:latest

 

  • 5 weeks later...

I'm looking for some help. I would like to setup borgmatic to backup my immich stuff nightly.

Data volume for immich is about 2tb. If I do a daily and keep 2 dailies, does that mean I need about 4tb or does it only include incremental information between the 2 version?

Ideally, I would like to backup daily to my own moving drive backup from my SSD, and then would like to backup weekly to my sister's TrueNas.

This is the information I have from Immich, but I don't know how to translate that to my server and borgmatic.

Backup Script | Immich
No image preview

Backup Script | Immich

Borg is a feature-rich deduplicating archiving software with built-in versioning. We provide a template bash script that can be run daily/weekly as a cron job to back up your files and database. We...

The location I have mapped for /mnt/user is /mnt/user and the location of immich is /mnt/user/immich.

Would this be correct for the config.yaml?

location:
    source_directories:
        - /boot
        - /mnt/user/appdata
        - /mnt/user/immich
    repositories:
        - /mnt/borg-repository
        - truenas.tailscale.net/backup:/mnt/disks/borg_remote/repo
    one_file_system: true
    files_cache: mtime,size
    patterns:
        - '- [Tt]rash'
        - '- [Cc]ache'
    exclude_if_present:
        - .nobackup
        - .NOBACKUP

storage:
    encryption_passphrase: "MYREPOPASSWORD"
    compression: none
    ssh_command: ssh -i /root/.ssh/id_rsa
    archive_name_format: 'backup-{now}'

retention:
    keep_hourly: 0
    keep_daily: 2
    keep_weekly: 1
    keep_monthly: 0
    keep_yearly: 0
    prefix: 'backup-'

consistency:
    checks:
        - repository
        - archives
    prefix: 'backup-'

hooks:
    before_backup:
        - echo "Starting a backup."
    after_backup:
        - echo "Finished a backup."
    on_error:
        - echo "Error during prune/create/check."

Then I need to put this in the crontab? to have it created daily and checked on Wednesday? But not sure how to tell it to do weekly to my sisters? Or does this just always do the same to my sister as it does here?

0 1    * * * borgmatic prune create -v 1 --stats 2>&1
0 6    * * 3 borgmatic check -v 1 2>&1
  • 2 weeks later...
  • Author

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/

Edited by sdub

  • 2 months later...

Hi!

I set up borgmatic yesterday, and ran the initial backup manually as you advised in your reddit post. After that it should run every day at 05:30, but it did not. Do you have any idea why? I did not get any ping either from healthchecks.

Container log snippet after starting the container:

[custom-init] Docker CLI variable not set, skipping...
[custom-init] No custom packages found, skipping...
-----------------------------------
Software Versions:
-----------------------------------
apprise 1.9.4
borg 1.4.1
borgmatic 2.0.7
dockercli not installed
composecli not installed
python 3.13.3
-----------------------------------
Time Zone: Europe/Budapest
-----------------------------------
Applying crontab.txt
Cron job set as: 
30 05 * * * borgmatic prune create -v 1 --stats 2>&1
00 02 * * 3 borgmatic check -v 1 2>&1
crond: crond (busybox 1.37.0) started, log level 8

crontab.txt config.yaml

Edited by Lecso

  • Author

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.

Edited by sdub

Hi @sdub !

The check was scheduled for today at 2am, and I got a healthchecks ping that it ran okay. However, the backup creation at 5:30 did not run again.

Healthchecks ping

The check Naspolya borgmatic is now UP.

Period: 1 day

Total Pings: 12

Last Ping: Success, 5 seconds ago

Last Ping Body:

Pinging Healthchecks start

Running consistency checks

Starting repository check

finished segment check at segment 353

Starting repository index check

Index object count match.

Finished full repository check, no problems found.

Starting archive consistency check...

Analyzing archive backup-2025-09-15T14:02:01 (1/1)

Orphaned objects check skipped (needs all archives checked).

Archive consistency check complete, no problems found.

Pinging Healthchecks log

Pinging Healthchecks finish

I ran the validator now.

borgmatic config validate -s

summary:

/etc/borgmatic.d/config.yaml: Configuration sections (like location:, storage:, retention:, consistency:, and hooks:) are deprecated and support will be removed from a future release. To prepare for this, move your options out of sections to the global scope.

/etc/borgmatic.d/config.yaml: before_backup is deprecated and support will be removed from a future release. Use commands: instead.

/etc/borgmatic.d/config.yaml: after_backup is deprecated and support will be removed from a future release. Use commands: instead.

/etc/borgmatic.d/config.yaml: on_error is deprecated and support will be removed from a future release. Use commands: instead.

/etc/borgmatic.d/config.yaml: The healthchecks hook now expects a key/value pair with "ping_url" as a key. String values for this option are deprecated and support will be removed from a future release.

/etc/borgmatic.d/config.yaml: The checks option now expects a list of key/value pairs. Lists of strings for this option are deprecated and support will be removed from a future release.

/etc/borgmatic.d/config.yaml: The repositories option now expects a list of key/value pairs. Lists of strings for this option are deprecated and support will be removed from a future release.

All configuration files are valid

I had a failed (the initial) backup, but after the fail I stopped the container, wiped the repo and re-initiated it with the init command.

I ran the backup creation right now with:

borgmatic prune create -v 1 --stats

/etc/borgmatic.d/config.yaml: Pinging Healthchecks start

/mnt/borg-repository: Pruning archives

------------------------------------------------------------------------------

Original size Compressed size Deduplicated size

Deleted data: 0 B 0 B 0 B

All archives: 340.51 GB 339.36 GB 168.06 GB

Unique chunks Total chunks

Chunk index: 93639 189168

------------------------------------------------------------------------------

/mnt/borg-repository: Running before create action command hook

Starting a backup.

/mnt/borg-repository: Creating archive

Creating archive at "/mnt/borg-repository::backup-2025-09-17T08:32:51"

------------------------------------------------------------------------------

Repository: /mnt/borg-repository

Archive name: backup-2025-09-17T08:32:51

Archive fingerprint: 9d0950789e8db40e7bb382949b7d030d00d5fa48356490725b6ab2fb5fc6a3fd

Time (start): Wed, 2025-09-17 08:32:51

Time (end): Wed, 2025-09-17 08:32:59

Duration: 7.24 seconds

Number of files: 34842

Utilization of max. archive size: 0%

------------------------------------------------------------------------------

Original size Compressed size Deduplicated size

This archive: 170.47 GB 169.90 GB 2.56 kB

All archives: 510.98 GB 509.25 GB 168.06 GB

Unique chunks Total chunks

Chunk index: 93641 283732

------------------------------------------------------------------------------

/mnt/borg-repository: Running after create action command hook

Finished a backup.

/etc/borgmatic.d/config.yaml: Pinging Healthchecks log

/etc/borgmatic.d/config.yaml: Pinging Healthchecks finish

summary:

/etc/borgmatic.d/config.yaml: Configuration sections (like location:, storage:, retention:, consistency:, and hooks:) are deprecated and support will be removed from a future release. To prepare for this, move your options out of sections to the global scope.

/etc/borgmatic.d/config.yaml: before_backup is deprecated and support will be removed from a future release. Use commands: instead.

/etc/borgmatic.d/config.yaml: after_backup is deprecated and support will be removed from a future release. Use commands: instead.

/etc/borgmatic.d/config.yaml: on_error is deprecated and support will be removed from a future release. Use commands: instead.

/etc/borgmatic.d/config.yaml: The healthchecks hook now expects a key/value pair with "ping_url" as a key. String values for this option are deprecated and support will be removed from a future release.

/etc/borgmatic.d/config.yaml: The checks option now expects a list of key/value pairs. Lists of strings for this option are deprecated and support will be removed from a future release.

/etc/borgmatic.d/config.yaml: The repositories option now expects a list of key/value pairs. Lists of strings for this option are deprecated and support will be removed from a future release.

/etc/borgmatic.d/config.yaml: Successfully ran configuration file

Does it look good? I couldn't notice any errors, but I did not get the healthchecks ping.

ps -a

PID USER TIME COMMAND

1 root 0:00 /package/admin/s6/command/s6-svscan -X3 -- /run/service

17 root 0:00 s6-supervise s6-svscan-log

18 root 0:00 s6-supervise s6-linux-init-shutdownd

19 root 0:00 /package/admin/s6/command/s6-log -bpd3 -- 1 /run/uncaught-logs

20 root 0:00 /package/admin/s6-linux-init/command/s6-linux-init-shutdownd -d3 -c /run/s6/basedir -g 3000 -C

30 root 0:00 s6-supervise svc-cron

31 root 0:00 s6-supervise s6rc-oneshot-runner

32 root 0:00 s6-supervise s6rc-fdholder

40 root 0:00 /package/admin/s6/command/s6-ipcserverd -1 -- /package/admin/s6/command/s6-ipcserver-access -v0 -E

76 root 0:00 /usr/sbin/crond -f -L /dev/stdout

108 root 0:00 sh

115 root 0:00 sh

121 root 0:00 /bin/bash

186 root 0:00 ps -a

I can't see any borg command running if I'm not mistaken. I ran the borg break-lock /mnt/borg-repositorycommand now.

borgmatic prune create -v 2 --stats --log-file /mnt/borg-repository/logs/backup.log

f6d3a11fb158:/# borgmatic prune create -v 2 --stats --log-file /mnt/borg-repository/logs/backup.log

/etc/borgmatic.d/config.yaml: Calling healthchecks hook function initialize_monitor

/etc/borgmatic.d/config.yaml: Calling healthchecks hook function ping_monitor

/etc/borgmatic.d/config.yaml: Pinging Healthchecks start

/etc/borgmatic.d/config.yaml: Using Healthchecks ping URL https://hc-ping.com/a0810a67-0d1d-42da-aacb-50935796e5e0/start

/etc/borgmatic.d/config.yaml: PGID=*** BORG_PASSPHRASE_FD=*** BORG_DEBUG_PASSPHRASE=*** BORG_DISPLAY_PASSPHRASE=*** BORG_RELOCATED_REPO_ACCESS_IS_OK=*** BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK=*** BORG_USE_CHUNKS_ARCHIVE=*** BORG_EXIT_CODES=*** borg --version --debug --show-rc

/etc/borgmatic.d/config.yaml: Borg 1.4.1

/mnt/borg-repository: Running actions for repository

/mnt/borg-repository: Pruning archives

/mnt/borg-repository: PGID=*** BORG_PASSPHRASE_FD=*** BORG_DEBUG_PASSPHRASE=*** BORG_DISPLAY_PASSPHRASE=*** BORG_RELOCATED_REPO_ACCESS_IS_OK=*** BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK=*** BORG_USE_CHUNKS_ARCHIVE=*** BORG_EXIT_CODES=*** borg prune --keep-daily 7 --keep-monthly 6 --keep-weekly 4 --glob-archives backup-* --stats --debug --show-rc /mnt/borg-repository

using builtin fallback logging configuration

33 self tests completed in 0.09 seconds

Verified integrity of /mnt/borg-repository/index.361

TAM-verified manifest

security: read previous location '/mnt/borg-repository'

security: read manifest timestamp '2025-09-17T06:32:59.148561'

security: determined newest manifest timestamp as 2025-09-17T06:32:59.148561

security: repository checks ok, allowing access

Verified integrity of /root/.cache/borg/a15f2bc90746ca9fa405b243e9a7a937f6238b6ccfa3c2f3fb4ef4c547817c34/chunks

security: read previous location '/mnt/borg-repository'

security: read manifest timestamp '2025-09-17T06:32:59.148561'

security: determined newest manifest timestamp as 2025-09-17T06:32:59.148561

security: repository checks ok, allowing access

Archive authentication DISABLED.

TAM-verified archive

Cleaned up 0 uncommitted segment files (== everything after segment 361).

Verified integrity of /mnt/borg-repository/hints.361

check_free_space: required bytes 566244018, free bytes 3544864014336

security: saving state for a15f2bc90746ca9fa405b243e9a7a937f6238b6ccfa3c2f3fb4ef4c547817c34 to /root/.config/borg/security/a15f2bc90746ca9fa405b243e9a7a937f6238b6ccfa3c2f3fb4ef4c547817c34

security: current location /mnt/borg-repository

security: key type 3

security: manifest timestamp 2025-09-17T06:43:09.081304

Verified integrity of /mnt/borg-repository/index.365

Archive authentication DISABLED.

TAM-verified archive

Archive authentication DISABLED.

TAM-verified archive

------------------------------------------------------------------------------

Original size Compressed size Deduplicated size

Deleted data: -170.47 GB -169.90 GB -12.02 kB

All archives: 340.51 GB 339.36 GB 168.06 GB

Unique chunks Total chunks

Chunk index: 93639 189168

------------------------------------------------------------------------------

terminating with success status, rc 0

/mnt/borg-repository: Running before create action command hook

/mnt/borg-repository: PGID=*** echo "Starting a backup."

Starting a backup.

/mnt/borg-repository: Creating archive

/mnt/borg-repository: Using runtime directory /tmp/borgmatic-aepdcj0l/borgmatic

/mnt/borg-repository: Calling bootstrap hook function remove_data_source_dumps

/mnt/borg-repository: Looking for bootstrap manifest files to remove in /tmp/borgmatic-*/borgmatic/bootstrap

/mnt/borg-repository: Calling btrfs hook function remove_data_source_dumps

/mnt/borg-repository: Calling lvm hook function remove_data_source_dumps

/mnt/borg-repository: Calling mariadb hook function remove_data_source_dumps

/mnt/borg-repository: Removing MariaDB data source dumps

/mnt/borg-repository: Calling mongodb hook function remove_data_source_dumps

/mnt/borg-repository: Removing MongoDB data source dumps

/mnt/borg-repository: Calling mysql hook function remove_data_source_dumps

/mnt/borg-repository: Removing MySQL data source dumps

/mnt/borg-repository: Calling postgresql hook function remove_data_source_dumps

/mnt/borg-repository: Removing PostgreSQL data source dumps

/mnt/borg-repository: Calling sqlite hook function remove_data_source_dumps

/mnt/borg-repository: Removing SQLite data source dumps

/mnt/borg-repository: Calling zfs hook function remove_data_source_dumps

/mnt/borg-repository: Calling bootstrap hook function dump_data_sources

/mnt/borg-repository: Writing patterns to /tmp/borgmatic-aepdcj0l/borgmatic/tmpzpbl9ib4:

R /mnt/user/immich/library

R /mnt/user/immich/backups

R /mnt/user/immich/profile

R /etc/borgmatic.d/config.yaml

R /tmp/borgmatic-aepdcj0l/./borgmatic/bootstrap

/mnt/borg-repository: PGID=*** BORG_PASSPHRASE_FD=*** BORG_DEBUG_PASSPHRASE=*** BORG_DISPLAY_PASSPHRASE=*** BORG_RELOCATED_REPO_ACCESS_IS_OK=*** BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK=*** BORG_USE_CHUNKS_ARCHIVE=*** BORG_EXIT_CODES=*** borg create --patterns-from /tmp/borgmatic-aepdcj0l/borgmatic/tmpzpbl9ib4 --one-file-system --files-cache mtime,size --stats --debug --show-rc /mnt/borg-repository::backup-{now}

using builtin fallback logging configuration

33 self tests completed in 0.10 seconds

Verified integrity of /mnt/borg-repository/index.365

TAM-verified manifest

security: read previous location '/mnt/borg-repository'

security: read manifest timestamp '2025-09-17T06:43:09.081304'

security: determined newest manifest timestamp as 2025-09-17T06:43:09.081304

security: repository checks ok, allowing access

Creating archive at "/mnt/borg-repository::backup-2025-09-17T08:43:10"

Verified integrity of /root/.cache/borg/a15f2bc90746ca9fa405b243e9a7a937f6238b6ccfa3c2f3fb4ef4c547817c34/chunks

Reading files cache ...

Verified integrity of /root/.cache/borg/a15f2bc90746ca9fa405b243e9a7a937f6238b6ccfa3c2f3fb4ef4c547817c34/files

security: read previous location '/mnt/borg-repository'

security: read manifest timestamp '2025-09-17T06:43:09.081304'

security: determined newest manifest timestamp as 2025-09-17T06:43:09.081304

security: repository checks ok, allowing access

Processing files ...

Cleaned up 0 uncommitted segment files (== everything after segment 365).

Verified integrity of /mnt/borg-repository/hints.365

check_free_space: required bytes 566244088, free bytes 3544863989760

security: saving state for a15f2bc90746ca9fa405b243e9a7a937f6238b6ccfa3c2f3fb4ef4c547817c34 to /root/.config/borg/security/a15f2bc90746ca9fa405b243e9a7a937f6238b6ccfa3c2f3fb4ef4c547817c34

security: current location /mnt/borg-repository

security: key type 3

security: manifest timestamp 2025-09-17T06:43:18.120322

Verified integrity of /mnt/borg-repository/index.369

Archive authentication DISABLED.

TAM-verified archive

Archive authentication DISABLED.

TAM-verified archive

Archive authentication DISABLED.

TAM-verified archive

------------------------------------------------------------------------------

Repository: /mnt/borg-repository

Archive name: backup-2025-09-17T08:43:10

Archive fingerprint: b2b91a64da87d60a69962d8ff7df0c9b773f8edbd046153c346a17e335472a4c

Time (start): Wed, 2025-09-17 08:43:11

Time (end): Wed, 2025-09-17 08:43:18

Duration: 7.11 seconds

Number of files: 34842

Utilization of max. archive size: 0%

------------------------------------------------------------------------------

Original size Compressed size Deduplicated size

This archive: 170.47 GB 169.90 GB 2.57 kB

All archives: 510.98 GB 509.25 GB 168.06 GB

Unique chunks Total chunks

Chunk index: 93641 283732

------------------------------------------------------------------------------

terminating with success status, rc 0

/mnt/borg-repository: Calling bootstrap hook function remove_data_source_dumps

/mnt/borg-repository: Looking for bootstrap manifest files to remove in /tmp/borgmatic-*/borgmatic/bootstrap

/mnt/borg-repository: Removing bootstrap manifest at /tmp/borgmatic-aepdcj0l/borgmatic/bootstrap/manifest.json

/mnt/borg-repository: Calling btrfs hook function remove_data_source_dumps

/mnt/borg-repository: Calling lvm hook function remove_data_source_dumps

/mnt/borg-repository: Calling mariadb hook function remove_data_source_dumps

/mnt/borg-repository: Removing MariaDB data source dumps

/mnt/borg-repository: Calling mongodb hook function remove_data_source_dumps

/mnt/borg-repository: Removing MongoDB data source dumps

/mnt/borg-repository: Calling mysql hook function remove_data_source_dumps

/mnt/borg-repository: Removing MySQL data source dumps

/mnt/borg-repository: Calling postgresql hook function remove_data_source_dumps

/mnt/borg-repository: Removing PostgreSQL data source dumps

/mnt/borg-repository: Calling sqlite hook function remove_data_source_dumps

/mnt/borg-repository: Removing SQLite data source dumps

/mnt/borg-repository: Calling zfs hook function remove_data_source_dumps

/mnt/borg-repository: Running after create action command hook

/mnt/borg-repository: PGID=*** echo "Finished a backup."

Finished a backup.

/etc/borgmatic.d/config.yaml: Calling healthchecks hook function ping_monitor

/etc/borgmatic.d/config.yaml: Pinging Healthchecks log

/etc/borgmatic.d/config.yaml: Using Healthchecks ping URL https://hc-ping.com/a0810a67-0d1d-42da-aacb-50935796e5e0/log

/etc/borgmatic.d/config.yaml: Calling healthchecks hook function ping_monitor

/etc/borgmatic.d/config.yaml: Pinging Healthchecks finish

/etc/borgmatic.d/config.yaml: Using Healthchecks ping URL https://hc-ping.com/a0810a67-0d1d-42da-aacb-50935796e5e0

/etc/borgmatic.d/config.yaml: Calling healthchecks hook function destroy_monitor

summary:

/etc/borgmatic.d/config.yaml: Loading configuration file

/etc/borgmatic.d/config.yaml: Configuration sections (like location:, storage:, retention:, consistency:, and hooks:) are deprecated and support will be removed from a future release. To prepare for this, move your options out of sections to the global scope.

/etc/borgmatic.d/config.yaml: before_backup is deprecated and support will be removed from a future release. Use commands: instead.

/etc/borgmatic.d/config.yaml: after_backup is deprecated and support will be removed from a future release. Use commands: instead.

/etc/borgmatic.d/config.yaml: on_error is deprecated and support will be removed from a future release. Use commands: instead.

/etc/borgmatic.d/config.yaml: The healthchecks hook now expects a key/value pair with "ping_url" as a key. String values for this option are deprecated and support will be removed from a future release.

/etc/borgmatic.d/config.yaml: The checks option now expects a list of key/value pairs. Lists of strings for this option are deprecated and support will be removed from a future release.

/etc/borgmatic.d/config.yaml: The repositories option now expects a list of key/value pairs. Lists of strings for this option are deprecated and support will be removed from a future release.

/etc/borgmatic.d/config.yaml: Successfully ran configuration file


I can see files modified in the repo after running this but I did not get a ping again.

Thanks for you help so far. I can't see why it is not working...

Edit:
On healthchecks.io i see the last ping was 7 minutes ago, when I ran the create command. I just did not get the ping. But I got the check one this night. I don't get it.

Edit2: I think I get it. I didn't know that there is a schedule for the pings. I created the correct schedule now.

backup.log

Edited by Lecso

  • 2 weeks later...

Hi!

What is the way to create a backup of a SSH source? I want to save some directories of a raspberry pi that I can access via SSH. I created the ssh keys in the container and copied them to the pi. What is the correct way to write the config.yaml for this?

Edit: I solved it by creating a samba share of the directory on the Pi and adding it to Unraid as a remote share, then mounting that to the docker container as a path.

Edited by Lecso

  • Author

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/

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.