BmuS Documentation

Frequently asked questions

Language files for the Docker version have not been updated

When a new Docker version is downloaded, BmuS immediately checks whether language files exist in the /config folder. This is not the case during the initial installation. Bmus then copies the language files from the Docker container to the /config folder.'

However, if language files from a previous installation are already there, BmuS does not overwrite them. The reason for this is that the user may have made changes to them that should not be overwritten.

The problem: If new functions have been added, there will also be new language variables. These will not be found. Text gaps may then appear in the logs or the dashboard.

Tip: Back up the language files from the /config folder to another directory. Restart the container. BmuS will now copy the new language files to the /config folder. Use a suitable text editor to compare the old and new versions, copy the new variables to the old language files, and update the version number to the latest version. Then copy the old (but updated) language files back to the /config folder.

Can I run BmuS in pull mode (NAS to NAS)?

Yes.

"Pull" mode is excellent for security (ransomware protection). Since BmuS is designed to run locally on the backup device, the logic is quite simple:

If you enter an IP, BmuS might try to run connectivity checks (Ping) or attempt to mount the destination itself, which isn't needed here.

The Setup: You need to mount your Primary NAS's SMB share to your Backup NAS's filesystem first (e.g., via /etc/fstab or OS mount to /mnt/primary_nas).

The Config: In BmuS, you then treat this mount simply as a local folder.

BACKUP_SOURCES="/mnt/primary_nas" (The path to your mounted SMB share)

BACKUP_PATH="/mnt/local_storage" (The local disk on your backup NAS)

Important: Please leave NAS_IP=""empty in your bmus.conf.

Since the mount is handled by the OS, BmuS treats this as a "Local Backup".

After restarting the Docker container, my rclone.conf file is gone

The /root/ directory within the container is volatile. When you stop the container (or restart the machine on which the container is running), the container is "thrown away" and recreated from the image upon restart. Anything not located within a volume (like /config) is then permanently lost.

BmuS prevents this by checking if an rclone.conf file exists in the Docker container. If so, BmuS checks if an rclone.conf file is located in the /config folder on the host. If it is not, or if the file is empty (0 Bytes), BmuS copies the rclone.conf file from the Docker container to the /config folder.

However, this only happens if CLOUD_BACKUP=1 is set in the bmus.conf file. If this is not the case, and you restart the container without this process having been carried out at least once AND directly after you have configured rclone, the rclone.conf file in the Docker container will be lost the moment you restart Docker.

Unless you plan to use cloud backup but still want to configure rclone in the Docker container prior performing a cloud backup, it's best to manually copy the rclone.conf file from the container to the /config directory.

Reconfigure rclone (if necessary):

docker exec -it bmus_backup rclone config

Manually copy the rclone.conf file into the /config folder:

docker exec -it bmus_backup cp /root/.config/rclone/rclone.conf /config/rclone.conf

Docker: I have configured and authorized rclone. Will the authorization be lost if I rebuild the Docker container?

No. If the backup has already been run with Cloud Backup, BmuS copied rclone.conf automatically from the Docker container to /BmuS-Docker/config, if it was not already there. If the file is already there, BmuS will always use this one, even if the Docker container is rebuilt or updated. The condition is that the path in bmus.conf is correct:

RCLONE_CFG_PATH="/config/rclone.conf"

I configured BmuS to use NFS for performance. Why does the script automatically switch to SMB/CIFS when the Cloud Backup starts?

This is an intentional "Auto-Pilot" feature designed to ensure the stability of your cloud uploads.

While NFS is superior for the local backup phase (transferring files from your Client/Host to the NAS/Network drive), it often causes significant issues during the Cloud Backup phase. Here is the detailed explanation of why BmuS performs this switch:

1. The Right Tool for the Job

• NFS (Network File System): BmuS prefers NFS for the main backup because it is extremely fast and handles Linux file permissions and metadata very well. It is the "race car" engine for rsync.
• SMB/CIFS (Samba): SMB is slightly slower but much more robust when it comes to file locking and broad compatibility. It is the "heavy-duty truck."

2. The Problem with Rclone & NFS

To upload your data to the cloud (OneDrive, Google Drive, etc.), BmuS uses a tool called rclone. In practice, running rclone on a mounted NFS share often leads to sporadic and frustrating errors, such as:

• "Stale File Handles": The connection to the file drops suddenly while reading.
• File Locking Issues: NFS and rclone disagree on who is allowed to access a file, causing the upload to freeze or crash.
• Timeouts: Large files might fail halfway through because the NFS protocol is optimized for speed/caching, while rclone needs a stable, continuous read stream.

3. The BmuS Solution

To prevent your Cloud Backup from failing silently or crashing:

1. BmuS detects that you are using NFS.
2. Before the cloud upload begins, it automatically unmounts the NFS share.
3. It remounts the same share using the SMB/CIFS protocol.
4. It performs the cloud upload safely and stably.

Summary: BmuS prioritizes Speed for your local backup and Stability for your cloud upload. You do not need to intervene; the script handles this protocol negotiation automatically in the background.

I don’t have a NAS. Can I backup on a SD or HD?

Yes. BmuS is very cooperative here if you configure it correctly.

Technically speaking, BmuS doesn't care whether the destination folder (BACKUP_PATH) is a mounted NAS, a USB hard drive, or an internal folder. The main thing is that it can write there.

Here is the behavior and necessary configuration for Native and Docker if you want to use a local hard drive (e.g., USB).

The behavior of the script (code level)

BmuS differentiates based on the NAS_IP variable:

1. If NAS_IP is set: BmuS assumes that it needs to mount a network drive (mount -t cifs …). It performs ping tests and attempts the mount.
2. If NAS_IP is EMPTY (“”): BmuS skips the entire network mount logic. It simply assumes: “The path specified in BACKUP_PATH is already there and ready.”

Native Installation

Configuration for native installation (e.g., Linux or Raspberry Pi with USB disk).

Let's assume you have a USB disk that your Linux automatically mounted to /media/usbdisk (or you entered it in /etc/fstab). To do this, simply empty .bmus_credentials

NAS_USER=""
NAS_PASS=""

and empty bmus.conf

NAS_IP=""
NAS_SHARE=""

Then mount the medium and enter the path to it in bmus.conf under BACKUP_PATH.

BACKUP_PATH=“/media/usbdisk/BmuS_Backup”

Docker Installation

Here, it is slightly different. The container does not see your hardware directly. You must “pass through” the USB disk from the host to the container.

Scenario: USB disk is mounted on the NAS/host under /mnt/usb_backup.

Adjusting docker-compose.yml: You have to change the volume. Instead of using the config folder, you map the real disk.

YAML

volumes:
  - ./config:/config
  - /:/host_root:ro
  # We map the USB disk in the container to /target
  - /mnt/usb_backup:/target

bmus.conf:

No NAS connection required in the container.

NAS_IP=""

The path INSIDE the container (see docker-compose).

BACKUP_PATH="/target/MyBackup"

Is it possible to start BmuS with different configs?

Yes.

Native installation

sudo CONFIG_FILE=/home/user/bmus_alternative.conf /home/user/bmus.sh

You can also add several cronjobs that execute different configs.

Open crontab.

sudo crontab -e

Daily at 3:00 a.m. and 6:00 a.m. with alternative configs.

0 3 * * * CONFIG_FILE=/home/user/bmus.conf /home/user/bmus.sh
0 6 * * * CONFIG_FILE=/home/user/bmus_alternative.conf /home/user/bmus.sh

Docker installation

sudo docker exec -it -e CONFIG_FILE=/config/bmus_alternative.conf bmus_backup /app/bmus.sh [ARGUMENTS]

Make sure that bmus_alternative.conf is in the config/ folder.

Daily at 3:00 a.m. and 6:00 a.m. with alternative docker configs.

0 4 * * * sudo docker exec -e CONFIG_FILE=/config/bmus.conf bmus_backup /app/bmus.sh
0 18 * * * sudo docker exec -e CONFIG_FILE=/config/bmus_alternative.conf bmus_backup /app/bmus.sh

You could also tweak the docker-compose.yml.

But since the Docker container (more precisely, the entrypoint.sh script) is hard-coded to always load /config/bmus.conf, you nee to use a “mount trick” here:

For the second container (bmus_alternative), we mount the file bmus_alternative.conf (from the host) directly over bmus.conf (in the container). The container “thinks” it is loading the default configuration, but in reality it is reading your second configuration.

services:
  # ---------------------------------------------------------
  # 1. Standard container (uses bmus.conf)
  # ---------------------------------------------------------
  bmus:
    image: backmeupscotty/bmus:latest
    container_name: bmus_backup
    restart: unless-stopped
    privileged: true
    volumes:
      - ./config:/config
      - /:/host_root:ro
    environment:
      - TZ=Europe/Berlin

  # ----------------------------------- ----------------------
  # 2. Second container (uses bmus_alternative.conf)
  # ------------------------------------------------------ ---
  bmus_secondary:
    image: backmeupscotty/bmus:latest
    container_name: bmus_backup_secondary
    restart: unless-stopped
    privileged: true
    volumes:
      # First mount the entire folder (for credentials, etc.)
      - ./config:/config
      
      # TRICK: We overwrite the bmus.conf in the container with the bmus_alternative.conf from the host
      - ./config/bmus_alternative.conf:/config/bmus.conf
      
      # OPTIONAL: We also redirect the log file so that they don't get mixed up
      # (Host: bmus_alternative.log -> Container: bmus.log)
      # IMPORTANT: Create an empty ‘bmus_alternative.log’ on the host beforehand!
      - ./config/bmus_alternative.log:/config/bmus.log
      
      - /:/host_root:ro
    environment:
      - TZ=Europe/Berlin

Both containers now run completely independently of each other. This means you can define completely different schedules (CRON_SCHEDULE), backup destinations, or sources in bmus_alternative.conf than in the first file.

Can I backup Windows?

Sure. But only with the Docker version and “Docker Desktop.”

1. Download and install Docker Desktop for Windows:
https://docs.docker.com/desktop/setup/install/windows-install/
2. Give Docker Desktop full access rights on your Windows PC.
3. Download the ZIP file Bmus-Docker.zip and unzip it.
4. Go to the folder where you unzipped Bmus-Docker.zip.
5. Open the Yaml and replace it with this:

services:
  bmus:
    image: backmeupscotty/bmus:latest
    container_name: bmus_backup
    restart: unless-stopped
    privileged: true
    cap_add:
      - SYS_ADMIN
      - DAC_READ_SEARCH
    environment:
      - TZ=Europe/Berlin # change to your time zone
    volumes:
      - ./config:/config
      # MAP YOUR WINDOWS DRIVES HERE:
      # Format: Drive:/Path:/host_root/Path
      - C:/Users/YourName:/host_root/YourName:ro
      # External Drive D:
      #- D:/Photos:/host_root/D/Photos:ro

6. Change to the /config folder
7. Open bmus.conf and configure it according to your preferences.

IMPORTANT: The most important difference is how you mount the drives. Windows uses drive letters (C:), Linux does not. Linux runs in the container. This means that you cannot use C:\ paths or backslashes \ in your configuration. You must specify the paths as they appear in the container.

Incorrect (Windows thinking):

BACKUP_SOURCES=(“C:\Users\YourName\Documents”)

Correct (Linux/Docker thinking):

BACKUP_SOURCES=(“/host_root/YourName/Documents”)

8. Remember to edit msmtp.conf (smtp config for mail reports), bmus_credentials (credentials to your NAS), and bmus_geocryptfs (Password file for encrypted backups).
9. Switch back from the /config folder to the root folder of the Bmus-Docker directory.

cd C:\Users\YourName\Bmus-Docker

10. Now you need to start loading and building the Docker image.
11. Enter the following command (CMD or PowerShell):

docker compose up -d

12. Once the image has loaded and appears in Docker Desktop, you are ready to proceed.
13. Open Notepad, copy the following code and save it to the root folder of Bmus-Docker as bmus.bat:

@echo off
REM ==========================================
REM BmuS wrapper for Windows
REM Forward commands to the Docker container
REM ==========================================

docker exec -it bmus_backup env CONFIG_FILE="/config/bmus.conf" /app/bmus.sh %*

14. Run Bmus for your first backup.

Type

bmus.bat 

or send the command into the container

docker exec -it bmus_backup env CONFIG_FILE="/config/bmus.conf" /app/bmus.sh

Optional:

If you want to call BmuS from anywhere (without always having to navigate to the folder first), you must add the folder containing the .bat file to the Windows PATH variable.

1. Press the Windows key + R, type sysdm.cpl, and press Enter.
2. Go to the Advanced tab -> Environment Variables.
3. In the lower section (“System variables”), find the line Path and click Edit.
4. Click New and paste the path to your folder (e.g., C:\Users\YourName\Bmus-Docker).
5. Confirm everything with OK.

If you then restart your terminal, you can simply type bmus wherever you are, and Windows will find the script automatically.

Can I back up (my Mac) to an external HD?

Yes, this works great. On macOS, external drives usually mount under /Volumes/NameOfDrive. You just need to map this path into the Docker container in your docker-compose.yml.

Example: - /Volumes/MyBackupDrive:/mnt/backup_drive

Ensure that you grant Docker Desktop permission to access "Removable Volumes" in your Mac's System Settings -> Privacy & Security -> Files and Folders (or "Full Disk Access"), otherwise the container might not see the external drive."

File System Requirements (Crucial for Mac): Because BmuS uses Hardlinks for deduplication (to save massive amounts of space), the file system matters:

• Recommended: APFS (Apple File System) or Mac OS Extended (HFS+). These are the native Mac formats. They support hardlinks perfectly. Since Docker maps the drive from macOS to the Linux container, BmuS can utilize the Mac's native file system features to create space-saving backups.
• Not Recommended: exFAT or FAT32. Many external drives come pre-formatted as exFAT. Do not use this for BmuS. exFAT does not support hardlinks. BmuS would still work, but it would have to create a full copy every single time instead of just saving the changes. Your drive would fill up very quickly.

Can I backup my Mac?

Absolutely. But only with the Docker version and “Docker Desktop.”

1. Download and install Docker Desktop for Mac:
   https://docs.docker.com/desktop/setup/install/mac-install/
2. Give Docker Desktop full access rights on your Mac.
3. Download the ZIP file Bmus-Docker.zip and unzip it.
4. Go to the folder where you unzipped Bmus-Docker.zip.
5. Open the Yaml and replace it with this:

services:
  bmus:
    # ---------------------------------------------------------
    # backmeupscotty
    # ---------------------------------------------------------
    #build: .
    image: backmeupscotty/bmus:latest
    container_name: bmus_backup
    restart: unless-stopped
    privileged: true
    cap_add:
      - SYS_ADMIN
      - DAC_READ_SEARCH
    
    volumes:     
      
      - /Users/your_mac_user_here:/host_root/Users/your_mac_user_here:ro
      - ./config:/config

    environment:
    # change to your time zone
      - TZ=Europe/Berlin

5. Change to the /config folder
6. Open bmus.conf and configure it according to your preferences.
7. IMPORTANT: The backup path under BACKUP_SOURCES under Mac always starts with
   /host_root/Users/your_mac_user/
   Example: “/host_root/Users/your_mac_user/Documents/PDF”
8. Remember to edit msmtp.conf (smtp config for mail reports), bmus_credentials (credentials to your NAS), and bmus_geocryptfs (Password file for encrypted backups).
9. Switch back from the /config folder to the root folder of the Bmus-Docker directory.
10. Give the bmus file execution permissions:

sudo chmod +x bmus

11. Now you need to start loading and building the Docker image.
12. Enter the following command:
    sudo docker compose up -d
13. Once the image has loaded and appears in Docker Desktop, you are ready to proceed.
14. Run Bmus for your first backup:
    sudo bmus or send the command into the container sudo docker exec -it bmus_backup /app/bmus.sh

This is what the wrapper code looks like:

#!/bin/bash

# Container is running?
if [ ! "$(sudo docker ps -q -f name=bmus_backup)" ]; then
    echo "Error: BmuS container is not running!"
    echo "Please start it first: sudo docker compose up -d"
    exit 1
fi

# Pass the command to the container
# “$@” passes all arguments (such as --restore --list) 1:1
sudo docker exec -it -e CONFIG_FILE=/config/bmus.conf bmus_backup /app/bmus.sh "$@"