Hello all!
I’ve integrated borgmatic exactly as guide explains
mailcow.github.io Icon Borgmatic Backup - mailcow: dockerized documentation

mailcow.github.io Icon mailcow.github.io
Borgmatic Backup - mailcow: dockerized documentation
None
mailcow.github.io

with the only difference that repository is a SSH to a private server.

I’ve noticed that, despite 140gb of mails, the backup is blazingly fast. After a check, the total amount of data for a backup is a few megs.

As the mails are backed up via another method, I’ve deleted and recreated the repository, just for be sure nothing was wrong during the setup.

Again, nothing. I’ve entered the running container
docker exec -it mailcowdockerized-borgmatic-mailcow-1 /bin/bash

and everyting I’ve set up on the docker-compose.override.yml is in place. All directories are mounted and RO.

If I launch borgmatic here inside the container, the backup completes in a matter of seconds. I see it backups some file from rspamd, the mysql database and nothing more.

If I try the same exact command but with –dry-run it starts to backup all the mail in the /mnt/source/vmail directory!!!

Why this works dry-running but not on normal operation?

Please help me

  • After a long and deserved break to refresh my mind, I’ve come back and finally found a workaround:
    in data/conf/borgmatic/etc/config.yaml I’ve specfied to backup the vmail directory

    source_directories:
        - /mnt/source
        - /mnt/source/vmail

    Now the backup completes with all the desired data

Hello,
i have exactly the same problem. No contents of the folders are backed up until the database backup. When I export the backup, the folders are all empty. Anyone know a solution to the problem?

Have something to say?

Join the community by quickly registering to participate in this discussion. We'd like to see you joining our great moo-community!

I think I found the “bug”. In the default config I could find the following:

    # Stay in same file system: do not cross mount points beyond
    # the given source directories. Defaults to false. But when a
    # database hook is used, the setting here is ignored and
    # one_file_system is considered true.
    # one_file_system: true

If I don’t make a database backup, everything works as desired. But I still can’t understand the background of the fact that the value is ignored with a database backup.

  • wb7 likes this.

By the way, I forgot to mention that I don’t use volumes in Docker, but link to the file system. That’s why there are also mount points in the borgmatic container. It will probably work with volumes.
The following link describes the background and also a workaround with two config files: projects.torsion.org Icon Why are "database hook" and "one_file_system" are linked together?

projects.torsion.org Icon projects.torsion.org
Why are "database hook" and "one_file_system" are linked together?
Hi, and yes, if I follow the "RTFM" approach, I would have saved a lot of time :-) I moved a service (mailcow) from one host to an other and after that, my borgmatic backups are nearly empty (empty folder) but success. I was clever enough to think thas related to the btrfs filesystem ...
projects.torsion.org

15 days later

After a long and deserved break to refresh my mind, I’ve come back and finally found a workaround:
in data/conf/borgmatic/etc/config.yaml I’ve specfied to backup the vmail directory

source_directories:
        - /mnt/source
        - /mnt/source/vmail

Now the backup completes with all the desired data

  • wb7 likes this.
10 months later

This should be mentioned in the documentation!!!

I had too much faith in this and never checked the backup archives. Now a client asks for a mail folder he deleted by accident and I find out vmail has not been backing up for months (ever I set it up tbh)..

10 months later
No one is typing