Stop backup in case mounting is unsuccessful (user-callback)

[Mailblocker]

Hi, I am using the user-callback script to mount my backup drive before starting a backup via cronie. This works as expected as long as the USB drive is connected. If no drive is connected nothing is mounted but the backup is executed anyways. This results into a backup stored on my root drive instead. Which is not what I want to achieve. In this case no backup should be done.

My user-callback script returns 1 as an error code when it is called with argument $3 beeing 5 or 7 in case no drive can be mounted.

What is the correct way to stop the backup process in this case? Do I need to return another exit code for this? Or should I check if something is mounted on the expected location (/mnt/backup) in the user-callback arg $3 = 1 (backup process begins) step? If yes do I need to return a certain exit code in this case?

Thanks!

[Mailblocker]

Checking if he drive is mounted in case arg $3 = 1 with:

if mount | grep /mnt/backup; then
    echo "Drive is mounted"
    exit 0
else
    echo "Drive is not mounted"
    exit 1
fi

Works for my use case. No backup is executed if the drive can not be mounted.

Only question left from my side: Is this exit code 1 ok to use? Or should I use a different one in case there is any handling implemented on the BIT side?

[gsker]

I'm pretty sure it doesn't matter to backintime. I like to indicate that exit codes were from bad code I wrote rather than something packaged and to indicate where the error came from. It's pretty obvious here though.

This is what I mean:

if mountpoint /mnt/backup ; then
  echo "SUCCESS: /mnt/backup is mounted."
else
   rc=$(( $? + 200 ))
  echo "ERROR: /mnt/backup is not mounted."\
  exit $rc
fi

[gsker]

@Mailblocker can we close this issue?

[emtiu]

What is the correct way to stop the backup process in this case? Do I need to return another exit code for this? Or should I check if something is mounted on the expected location (/mnt/backup) in the user-callback arg $3 = 1 (backup process begins) step? If yes do I need to return a certain exit code in this case?

I found a simpler solution in the same situation. You don't even need any user-callback script. Just configure backintime to use a subfolder of the removable volume, instead of the root directory. It works like this:

1. If your drive is mounted at /mnt/mydrive, configure backintime to use /mnt/mydrive/backup (or something).
2. If the drive is mounted: /mnt/mydrive/backup exists, and backintime runs a backup into it.
3. If the drive is unmounted: /mnt/mydrive exists, but /mnt/mydrive/backup doesn't. backintime simply refuses to take a snapshot, because the backup target directory doesn't exist.

Please close this issue if this helps you :)

[Mailblocker]

What is the correct way to stop the backup process in this case? Do I need to return another exit code for this? Or should I check if something is mounted on the expected location (/mnt/backup) in the user-callback arg $3 = 1 (backup process begins) step? If yes do I need to return a certain exit code in this case?

I found a simpler solution in the same situation. You don't even need any user-callback script. Just configure backintime to use a subfolder of the removable volume, instead of the root directory. It works like this:

1. If your drive is mounted at `/mnt/mydrive`, configure backintime to use `/mnt/mydrive/backup` (or something).

2. If the drive is **mounted**: `/mnt/mydrive/backup` exists, and backintime runs a backup into it.

3. If the drive is **unmounted**: `/mnt/mydrive` exists, but `/mnt/mydrive/backup` doesn't. backintime simply refuses to take a snapshot, because the backup target directory doesn't exist.

Please close this issue if this helps you :)

In my case my drive mounted to root "/" was then used to store the backup. Which resulted in a full SSD drive and other OS related problems. As mentioned in my first post.

[emtiu]

In my case my drive mounted to root "/" was then used to store the backup. Which resulted in a full SSD drive and other OS related problems. As mentioned in my first post.

I understand. As I explained, this should not happen when you select a folder that does not exist as long as the target drive is unmounted.

Does this strategy work for you?

[Mailblocker]

Since I got a working solution I haven't tried your way. The only thing I can contribute in this case is that I haven't created the path on my root drive. For me it seems backintime created the needed path on its own or I messed something up a long time ago and the folder structure already existed.

[buhtz]

The "bug" was also reported on Debian. 995257@bugs.debian.org

It seems to me that we should re-open that Issue and take a closer look to it (sometimes).

[emtiu]

The "bug" was also reported on Debian. 995257@bugs.debian.org

It seems to me that we should re-open that Issue and take a closer look to it (sometimes).

All right, thanks for the link!

[aryoda]

The current status and possible solutions are described in this issue comment: https://github.com/bit-team/backintime/issues/827#issuecomment-1265953991

The big issue is that errors are catched, logged and ignored too deep under the hood but should bubble up instead.

This is difficult to implement due to the async nature of backups (requires some reliable Inter-Process Communication - IPC)

@emtiu Could you please add the user-callback label? THX!

[aryoda]

BTW:

Adding the set -o pipefail -e option to the user-callback bash script could improve the error discovering and a little bit.

For details see: https://github.com/bit-team/backintime/issues/827#issuecomment-1243469336