Bind mounts disappear after Borg backup

Support
, , ,
1

What type of hardware are you using: Raspberry Pi 3, 4+
What YunoHost version are you running: 12.1.39 (stable)
How are you able to access your server: The webadmin
SSH

Describe your issue

Hello,

I’m experiencing an issue where specific bind mounts disappear after running a YunoHost Borg backup, while others remain intact.

Context:
I have a Raspberry Pi 5 running YunoHost with an external USB 3.0 HDD (3TB Toshiba) for additional storage. I’ve followed the external storage documentation to move data to this HDD using bind mounts.

My setup:
hdd mount: /dev/sdb1 mounted at /mnt/hdd

Bind mounts in /etc/fstab:

UUID="<uuid>" /mnt/hdd ext4 defaults,nofail 0 0
/mnt/hdd/yunohost/home/yunohost.backup /home/yunohost.backup none defaults,bind 0 0
/mnt/hdd/yunohost/home/yunohost.multimedia/share/Series /home/yunohost.multimedia/share/Series none defaults,bind 0 0
/mnt/hdd/yunohost/home/yunohost.multimedia/share/Video /home/yunohost.multimedia/share/Video none defaults,bind 0 0

Problem:
After the Borg backup completes successfully, the bind mounts for Series and Video disappear, but /home/yunohost.backup remains mounted.

Before backup:

$ lsblk
sdb      8:16   0   2.7T  0 disk 
└─sdb1   8:17   0   2.7T  0 part /home/yunohost.multimedia/share/Video
                                 /home/yunohost.multimedia/share/Series
                                 /home/yunohost.backup
                                 /mnt/hdd

After backup:

$ lsblk
sdb      8:16   0   2.7T  0 disk 
└─sdb1   8:17   0   2.7T  0 part /home/yunohost.backup
                                 /mnt/hdd

The backup itself succeeds without errors. From the Borg service journal, I can see it backs up data_multimedia (11GB) along with all apps.

The bind mounts can be manually restored with:

mount --bind /mnt/hdd/yunohost/home/yunohost.multimedia/share/Series /home/yunohost.multimedia/share/Series
mount --bind /mnt/hdd/yunohost/home/yunohost.multimedia/share/Video /home/yunohost.multimedia/share/Video
  • HDD health: Checked with smartctl - no errors, no reallocated sectors, UDMA_CRC_Error_Count: 0
  • dmesg: No USB disconnects, resets, or errors
  • Backup logs: Show successful completion for all backup items including data_multimedia: Success

Question:
Why do these specific bind mounts disappear after the Borg backup, while /home/yunohost.backup remains? Is the data_multimedia backup hook (/usr/share/yunohost/hooks/backup/18-data_multimedia) intentionally unmounting these directories without remounting them afterwards?

Thank you for any insights!

Share relevant logs or error messages

var/log/borg/260227_0818.log: https://paste.yunohost.org/raw/itonusawub
journalctl -u borg: https://paste.yunohost.org/raw/tekilusuhi
dmesg | grep -i “usb|reset|disconnect” | tail -50: https://paste.yunohost.org/raw/xewakudodi
smartctl -a /dev/sdb: https://paste.yunohost.org/raw/ajohavuliy

2

Hello again,

I’ve taken a closer look at the journal logs using journalctl:

It clearly shows that the two affected bind mounts (Series and Video) are being explicitly unmounted by systemd - along with several temporary mount points that are created during the backup process.

The mount units related to tmp-auto_data-data-multimedia are deactivated at the exact same timestamp, while /home/yunohost.backup itself remains mounted:

Mar 03 09:41:56 <usr> systemd[1]: home-yunohost.backup-tmp-auto_data-data-multimedia-share-Video.mount: Deactivated successfully.
Mar 03 09:41:56 <usr> systemd[1]: home-yunohost.backup-tmp-auto_data-data-multimedia-share-Series.mount: Deactivated successfully.
Mar 03 09:41:56 <usr> systemd[1]: home-yunohost.multimedia-share-Video.mount: Deactivated successfully.
Mar 03 09:41:56 <usr> systemd[1]: home-yunohost.multimedia-share-Series.mount: Deactivated successfully.
Mar 03 09:41:56 <usr> systemd[1]: mnt-hdd-yunohost-home-yunohost.backup-tmp-auto_data-data-multimedia.mount: Deactivated successfully.
Mar 03 09:41:56 <usr> systemd[1]: home-yunohost.backup-tmp-auto_data-data-multimedia.mount: Deactivated successfully.

You can find the relevant Yunopaste Link here.

This strongly suggests that something in the YunoHost backup workflow - possibly the data_multimedia backup hook - is explicitly unmounting these directories.

Since these mounts are defined in /etc/fstab, I would normally expect them to persist.

Has anyone observed similar behavior when bind-mounting subdirectories of yunohost.multimedia to external storage?

Thanks again!

3

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

5

Hi, the same issue is happening on Restic for YunoHost, it’s a Debian or YunoHost issue.

You can modify your external mount so that only /home/yunohost.backup/archives is mounted externally, and /home/yunohost.backup/tmp remains on the main hard drive so that it can’t be unmounted.

6

Thanks for the hint! That’s an interesting approach, but I’m concerned that tmp is used as a staging area during backups and could temporarily require significant space on the main drive - depending on how much data is being backed up. Also, would this approach also cover bind mounts outside of yunohost.backup, e.g. under yunohost.multimedia?

7

I was able to fix this issue with the following workaround - it’s been running reliably for several weeks now. There may well be simpler or more elegant solutions out there - this is just what works for me. I will also try the approach suggested above. Provided that sufficient free space is available and the method supports bind mounts outside of yunohost.backup, it could prove to be the cleaner long-term solution.

The idea is a small restore script that checks the bind mounts after every Borg backup and re-establishes any that are missing, triggered automatically via a systemd drop-in.

Note: All paths used below are examples. Make sure to adapt them to match your own setup!

1. Create the restore script

nano /opt/borg/hdd-mounts/bin/hdd-mounts.sh
`hdd-mounts.sh` 
#!/bin/bash
LOGFILE="/var/log/hdd-mounts/hdd-mounts.log"
log() { echo "$(date '+%Y-%m-%d %H:%M:%S') - $1" >> "$LOGFILE"; }

# Adjust to your actual HDD mount point
if ! mountpoint -q /mnt/hdd; then
    log "WARNING: /mnt/hdd not mounted, attempting to mount..."
    mount /mnt/hdd && log "OK: /mnt/hdd mounted" || { log "ERROR: failed to mount /mnt/hdd"; exit 1; }
fi

# Add or remove entries to match your fstab bind mounts
declare -A MOUNTS=(
    ["/home/yunohost.backup"]="/mnt/hdd/yunohost.backup"
    ["/home/yunohost.multimedia/share/Series"]="/mnt/hdd/Series"
    ["/home/yunohost.multimedia/share/Video"]="/mnt/hdd/Video"
)

REMOUNTED=0
for TARGET in "${!MOUNTS[@]}"; do
    if ! mountpoint -q "$TARGET"; then
        log "WARNING: $TARGET missing, remounting..."
        mount --bind "${MOUNTS[$TARGET]}" "$TARGET" \
            && { log "OK: $TARGET restored"; ((REMOUNTED++)); } \
            || log "ERROR: could not mount $TARGET"
    fi
done

[ $REMOUNTED -gt 0 ] && log "INFO: $REMOUNTED mount(s) restored"
exit 0

2. Allow the borg user to run the script without a password

The Borg service runs as the borg user, not root, so a sudoers rule is needed:

visudo -f /etc/sudoers.d/hdd-mounts

User_Alias BORG_USERS = borg
BORG_USERS ALL=(root) NOPASSWD: /opt/borg/hdd-mounts/bin/hdd-mounts.sh

If you have multiple Borg instances (e.g. borg__2), add them to BORG_USERS accordingly.

3. Hook the script into Borg via a systemd drop-in

nano /etc/systemd/system/borg.service.d/hdd-mounts.conf

[Service]
ExecStartPost=/usr/bin/sudo /opt/borg/hdd-mounts/bin/hdd-mounts.sh

If you have additional Borg instances, create the same drop-in for each one.

systemctl daemon-reload

4. Test it

Run the script manually first to verify it works, then trigger a Borg backup and check that the mounts survive:

sudo /opt/borg/hdd-mounts/bin/hdd-mounts.sh
sudo systemctl start borg
lsblk
cat /var/log/hdd-mounts/hdd-mounts.log

Hope this helps - and if anyone knows a cleaner way to handle this, feel free to share!

1 Like