Unmount FS before backup to avoid failure due to lock #845

Open
opened 2024-03-30 12:06:27 +00:00 by knedlyk · 9 comments

Hi! I use systemd to regularly backup the system with the help of bormgatic.
Sometimes I mount it and sometimes forget to unmount :/ This, of course, blocks from running next backups.
Would you help to find out how to forcedly unmount the FS before starting the backup procedure? Eg via hook.

Additionally, it may be added to the configuration as an option: if mounted:

  1. warn and not to proceed with any operation
  2. unmount FS and proceed

What do you think?

Hi! I use systemd to regularly backup the system with the help of bormgatic. Sometimes I mount it and sometimes forget to unmount :/ This, of course, blocks from running next backups. Would you help to find out how to forcedly unmount the FS before starting the backup procedure? Eg via hook. Additionally, it may be added to the configuration as an option: if mounted: 1) warn and not to proceed with any operation 2) unmount FS and proceed What do you think?
knedlyk changed title from Unmount FS before backup to Unmount FS before backup to avoid failure due to lock 2024-03-30 12:07:39 +00:00
Owner

I haven't tested it, but you might be able to just do something like:

before_backup:
    umount /your/mount/point

I would recommend trying it both with the filesystem mounted and unmounted to make sure it doesn't error.

Or if you'd prefer you can put that in before_actions or even before_everything. See the hook documentation for more information.

As for a configuration option, I'm not necessarily averse to it, but it does seem a little specialized and I'm not sure how it would figure out which mount point paths to use (unless that's also part of the configuration). I'd recommend trying the hook approach first and seeing how that goes!

I haven't tested it, but you might be able to just do something like: ``` before_backup: umount /your/mount/point ``` I would recommend trying it both with the filesystem mounted and unmounted to make sure it doesn't error. Or if you'd prefer you can put that in `before_actions` or even `before_everything`. See [the hook documentation](https://torsion.org/borgmatic/docs/how-to/add-preparation-and-cleanup-steps-to-backups/) for more information. As for a configuration option, I'm not necessarily averse to it, but it does seem a little specialized and I'm not sure how it would figure out which mount point paths to use (unless that's also part of the configuration). I'd recommend trying the hook approach first and seeing how that goes!
witten added the
question / support
label 2024-04-01 16:27:31 +00:00
Author

I haven't tested it, but you might be able to just do something like:

before_backup:
    umount /your/mount/point

I would recommend trying it both with the filesystem mounted and unmounted to make sure it doesn't error.

Or if you'd prefer you can put that in before_actions or even before_everything. See the hook documentation for more information.

As for a configuration option, I'm not necessarily averse to it, but it does seem a little specialized and I'm not sure how it would figure out which mount point paths to use (unless that's also part of the configuration). I'd recommend trying the hook approach first and seeing how that goes!

Hi! The command should rather look like:

borgmatic umount --mount-point /my/mount-point

But, in case it is already unmounted it will return non-zero exit status, what will influence negatively on the next steps of borgmatic process.

borgmatic umount --mount-point /mnt/backup
Starting actions.
Finished actions.
Error unmounting mount point
Command 'borg umount /mnt/backup' returned non-zero exit status 1.

summary:
Error unmounting mount point
fusermount: failed to unmount /mnt/backup: Invalid argument
Command 'borg umount /mnt/backup' returned non-zero exit status 1.

Need some help? https://torsion.org/borgmatic/#issues

UPD: my suggestion:

borgmatic umount --mount-point /mnt/backup 2> /dev/null || true
> I haven't tested it, but you might be able to just do something like: > > ``` > before_backup: > umount /your/mount/point > ``` > > I would recommend trying it both with the filesystem mounted and unmounted to make sure it doesn't error. > > Or if you'd prefer you can put that in `before_actions` or even `before_everything`. See [the hook documentation](https://torsion.org/borgmatic/docs/how-to/add-preparation-and-cleanup-steps-to-backups/) for more information. > > As for a configuration option, I'm not necessarily averse to it, but it does seem a little specialized and I'm not sure how it would figure out which mount point paths to use (unless that's also part of the configuration). I'd recommend trying the hook approach first and seeing how that goes! Hi! The command should rather look like: ``` borgmatic umount --mount-point /my/mount-point ``` But, in case it is already unmounted it will return non-zero exit status, what will influence negatively on the next steps of borgmatic process. ``` borgmatic umount --mount-point /mnt/backup Starting actions. Finished actions. Error unmounting mount point Command 'borg umount /mnt/backup' returned non-zero exit status 1. summary: Error unmounting mount point fusermount: failed to unmount /mnt/backup: Invalid argument Command 'borg umount /mnt/backup' returned non-zero exit status 1. Need some help? https://torsion.org/borgmatic/#issues ``` UPD: my suggestion: ``` borgmatic umount --mount-point /mnt/backup 2> /dev/null || true ```
Owner

I generally don't recommend running borgmatic from borgmatic, just to avoid the risk of infinite recursion. And borgmatic umount is really a thin wrapper around umount, so you're not losing much of anything by running umount directly.

But to prevent umount's non-zero exit status from causing an error when nothing is mounted, you can try this:

before_backup:
    umount /your/mount/point || true
I generally don't recommend running borgmatic from borgmatic, just to avoid the risk of infinite recursion. And `borgmatic umount` is really a thin wrapper around `umount`, so you're not losing much of anything by running `umount` directly. But to prevent umount's non-zero exit status from causing an error when nothing is mounted, you can try this: ``` before_backup: umount /your/mount/point || true ```
Author

I generally don't recommend running borgmatic from borgmatic, just to avoid the risk of infinite recursion. And borgmatic umount is really a thin wrapper around umount, so you're not losing much of anything by running umount directly.

But to prevent umount's non-zero exit status from causing an error when nothing is mounted, you can try this:

before_backup:
    umount /your/mount/point || true

should be:

sudo umount /your/mount/point || true
> I generally don't recommend running borgmatic from borgmatic, just to avoid the risk of infinite recursion. And `borgmatic umount` is really a thin wrapper around `umount`, so you're not losing much of anything by running `umount` directly. > > But to prevent umount's non-zero exit status from causing an error when nothing is mounted, you can try this: > > ``` > before_backup: > umount /your/mount/point || true > ``` should be: ``` sudo umount /your/mount/point || true ```
Owner

Yes, sudo would be needed if you're running as a non-root user. But be aware that sudo can prompt for a password, which would be problematic if used non-interactively.

Yes, `sudo` would be needed if you're running as a non-root user. But be aware that `sudo` can prompt for a password, which would be problematic if used non-interactively.
Author

Yes, sudo would be needed if you're running as a non-root user. But be aware that sudo can prompt for a password, which would be problematic if used non-interactively.

strangely, this didn't work:

кві 13 02:56:02 hostname borgmatic[651697]: INFO /etc/borgmatic/config.yaml: Running 2 commands for pre-everything hook
кві 13 02:56:02 hostname systemd-inhibit[651697]: Starting actions.
кві 13 02:56:02 hostname borgmatic[651697]: WARNING Starting actions.
кві 13 02:56:02 hostname sudo[651718]:     root : PWD=/ ; USER=root ; COMMAND=/usr/bin/umount /mnt/backup
кві 13 02:56:02 hostname sudo[651718]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0)
кві 13 02:56:02 hostname systemd-inhibit[651697]: umount: /mnt/backup: must be superuser to unmount.
кві 13 02:56:02 hostname borgmatic[651697]: WARNING umount: /mnt/backup: must be superuser to unmount.
> Yes, `sudo` would be needed if you're running as a non-root user. But be aware that `sudo` can prompt for a password, which would be problematic if used non-interactively. strangely, this didn't work: ``` кві 13 02:56:02 hostname borgmatic[651697]: INFO /etc/borgmatic/config.yaml: Running 2 commands for pre-everything hook кві 13 02:56:02 hostname systemd-inhibit[651697]: Starting actions. кві 13 02:56:02 hostname borgmatic[651697]: WARNING Starting actions. кві 13 02:56:02 hostname sudo[651718]: root : PWD=/ ; USER=root ; COMMAND=/usr/bin/umount /mnt/backup кві 13 02:56:02 hostname sudo[651718]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0) кві 13 02:56:02 hostname systemd-inhibit[651697]: umount: /mnt/backup: must be superuser to unmount. кві 13 02:56:02 hostname borgmatic[651697]: WARNING umount: /mnt/backup: must be superuser to unmount. ```
Owner

Are you running borgmatic as the root user? If so, then you don't need sudo at all.

Are you running borgmatic as the root user? If so, then you don't need `sudo` at all.
Author

Are you running borgmatic as the root user? If so, then you don't need sudo at all.

I run borgmatic as a root, but it doesn't work without sudo the same.

This is my borgmatic.service unit file

# cat borgmatic.service
[Unit]
Description=borgmatic backup
Wants=network-online.target
After=network-online.target
ConditionACPower=true

[Service]
Type=oneshot

LockPersonality=true
MemoryDenyWriteExecute=no
NoNewPrivileges=yes
PrivateDevices=yes
PrivateTmp=yes
ProtectClock=yes
ProtectControlGroups=yes
ProtectHostname=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 AF_NETLINK
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
SystemCallArchitectures=native
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM
ProtectSystem=full

ReadWritePaths=/media/backup/system

#CapabilityBoundingSet=CAP_DAC_READ_SEARCH CAP_NET_RAW

Nice=19
CPUSchedulingPolicy=batch
IOSchedulingClass=best-effort
IOSchedulingPriority=7
IOWeight=100

Restart=no
LogRateLimitIntervalSec=0

ExecStartPre=sleep 1m
ExecStart=systemd-inhibit --who="borgmatic" --why="Prevent interrupting scheduled backup" borgmatic --syslog-verbosity 1
> Are you running borgmatic as the root user? If so, then you don't need `sudo` at all. I run borgmatic as a root, but it doesn't work without sudo the same. This is my borgmatic.service unit file ``` # cat borgmatic.service [Unit] Description=borgmatic backup Wants=network-online.target After=network-online.target ConditionACPower=true [Service] Type=oneshot LockPersonality=true MemoryDenyWriteExecute=no NoNewPrivileges=yes PrivateDevices=yes PrivateTmp=yes ProtectClock=yes ProtectControlGroups=yes ProtectHostname=yes ProtectKernelLogs=yes ProtectKernelModules=yes ProtectKernelTunables=yes RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 AF_NETLINK RestrictNamespaces=yes RestrictRealtime=yes RestrictSUIDSGID=yes SystemCallArchitectures=native SystemCallFilter=@system-service SystemCallErrorNumber=EPERM ProtectSystem=full ReadWritePaths=/media/backup/system #CapabilityBoundingSet=CAP_DAC_READ_SEARCH CAP_NET_RAW Nice=19 CPUSchedulingPolicy=batch IOSchedulingClass=best-effort IOSchedulingPriority=7 IOWeight=100 Restart=no LogRateLimitIntervalSec=0 ExecStartPre=sleep 1m ExecStart=systemd-inhibit --who="borgmatic" --why="Prevent interrupting scheduled backup" borgmatic --syslog-verbosity 1 ```
Owner

My guess is that some of the systemd security settings (something from LockPersonality to ReadWritePaths) are interfering with your umount command. So my recommendation is to try removing some or all of these settings and then reloading the systemd daemon (systemctl daemon-reload) to make those changes take effect.

My guess is that some of the systemd security settings (something from `LockPersonality` to `ReadWritePaths`) are interfering with your `umount` command. So my recommendation is to try removing some or all of these settings and then reloading the systemd daemon (`systemctl daemon-reload`) to make those changes take effect.
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: borgmatic-collective/borgmatic#845
No description provided.