creativeprojects
Ubuntu: Scheduled backup is forgotten after reboot
When I run
resticprofile schedule
to schedule a daily backup on my Ubuntu machine, it works perfectly until I next reboot. But after the reboot, no backups occur until I run
resticprofile schedule
again. Is this deliberate? And if not, is there anything I can do to help narrow down what's going wrong?
Thanks.
No this is definitely not deliberate. There's something funny on your system that resets the systemd configuration.
I can't think of anything that could do that, but I guess any system controlled by an organisation could change things when they don't like it; or a system that keeps all configuration files in a specific state; it could be anything really 🤷🏻
I’m happy to help debug this if you can suggest where to look. This is a machine 100% managed by me, and I recently reinstalled, so it’s definitely not any kind of corporate control software.
On Sep 1, 2025, at 1:06 PM, Fred @.***> wrote:
creativeprojects left a comment (creativeprojects/resticprofile#558) https://github.com/creativeprojects/resticprofile/issues/558#issuecomment-3243188700 No this is definitely not deliberate. There's something funny on your system that resets the systemd configuration.
I can't think of anything that could do that, but I guess any system controlled by an organisation could change things when they don't like it; or a system that keeps all configuration files in a specific state; it could be anything really 🤷🏻
— Reply to this email directly, view it on GitHub https://github.com/creativeprojects/resticprofile/issues/558#issuecomment-3243188700, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQNZDQQE4MHS6WAEN4LPCL3QSRNTAVCNFSM6AAAAACFIO4CEGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENBTGE4DQNZQGA. You are receiving this because you authored the thread.
I think I know what’s causing it. I have my home directory encrypted, and I decrypt when first logging on. My guess is that the timers are set up before the decryption occurs, causing the scheduled backups not to occur after a reboot. I’ll do some more investigating.
On Sep 1, 2025, at 2:15 PM, Richard Stanton @.***> wrote:
I’m happy to help debug this if you can suggest where to look. This is a machine 100% managed by me, and I recently reinstalled, so it’s definitely not any kind of corporate control software.
On Sep 1, 2025, at 1:06 PM, Fred @.***> wrote:
creativeprojects left a comment (creativeprojects/resticprofile#558) https://github.com/creativeprojects/resticprofile/issues/558#issuecomment-3243188700 No this is definitely not deliberate. There's something funny on your system that resets the systemd configuration.
I can't think of anything that could do that, but I guess any system controlled by an organisation could change things when they don't like it; or a system that keeps all configuration files in a specific state; it could be anything really 🤷🏻
— Reply to this email directly, view it on GitHub https://github.com/creativeprojects/resticprofile/issues/558#issuecomment-3243188700, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQNZDQQE4MHS6WAEN4LPCL3QSRNTAVCNFSM6AAAAACFIO4CEGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENBTGE4DQNZQGA. You are receiving this because you authored the thread.
That was the problem. Now solved (I restart the timers after decrypting the partition).
On Sep 1, 2025, at 2:31 PM, Richard Stanton @.***> wrote:
I think I know what’s causing it. I have my home directory encrypted, and I decrypt when first logging on. My guess is that the timers are set up before the decryption occurs, causing the scheduled backups not to occur after a reboot. I’ll do some more investigating.
On Sep 1, 2025, at 2:15 PM, Richard Stanton @.***> wrote:
I’m happy to help debug this if you can suggest where to look. This is a machine 100% managed by me, and I recently reinstalled, so it’s definitely not any kind of corporate control software.
On Sep 1, 2025, at 1:06 PM, Fred @.***> wrote:
creativeprojects left a comment (creativeprojects/resticprofile#558) https://github.com/creativeprojects/resticprofile/issues/558#issuecomment-3243188700 No this is definitely not deliberate. There's something funny on your system that resets the systemd configuration.
I can't think of anything that could do that, but I guess any system controlled by an organisation could change things when they don't like it; or a system that keeps all configuration files in a specific state; it could be anything really 🤷🏻
— Reply to this email directly, view it on GitHub https://github.com/creativeprojects/resticprofile/issues/558#issuecomment-3243188700, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQNZDQQE4MHS6WAEN4LPCL3QSRNTAVCNFSM6AAAAACFIO4CEGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENBTGE4DQNZQGA. You are receiving this because you authored the thread.
Cool, good to know!
What are you using for encrypting your home? Would it make sense to document your fix, or is it very much home-made?
It’s homemade, but others might find it useful.
I have a simple .bashrc for my first login, which decrypts the encrypted partition, mounts the relevant directories (which, in particular, replaces the original simple .bashrc with my “real” version), and (now) restarts the resticprofile timers. Running this requires me to log in over SSH the first time.
The relevant piece of the (initial) .bashrc looks like this:
--- Decrypt and mount data directories on first interactive terminal ---
Only run if marker directory isn't there yet
if [ ! -d "$HOME/projects/_research" ]; then lock="/run/user/$UID/unlock.lock" exec 9>"$lock" if flock -n 9; then # Run script. Using </dev/tty ensures passphrase prompts appear here. "$HOME/unlock-and-mount.sh" </dev/tty >/dev/tty 2>&1 || { echo "[unlock] ~/unlock-and-mount.sh failed (exit $?)" } fi fi
And the script that does all the work looks like this:
#!/bin/bash set -e
Name of the LUKS mapping and device
LUKS_DEVICE_UUID=“XXXXXXXX" LUKS_DEVICE="UUID=$LUKS_DEVICE_UUID" MAPPER_NAME="data_crypt" MOUNT_POINT="/data" BIND_MOUNT_TARGETS=("stanton") HOME_ROOT="/home"
Unlock the encrypted device if not already unlocked
if [ ! -e /dev/mapper/$MAPPER_NAME ]; then echo "🔐 Unlocking encrypted partition $LUKS_DEVICE..." sudo cryptsetup luksOpen "$LUKS_DEVICE" "$MAPPER_NAME" else echo "✅ Device already unlocked: /dev/mapper/$MAPPER_NAME" fi
Mount the decrypted volume
if ! mountpoint -q "$MOUNT_POINT"; then echo "📦 Mounting /dev/mapper/$MAPPER_NAME at $MOUNT_POINT..." sudo mount "/dev/mapper/$MAPPER_NAME" "$MOUNT_POINT" else echo "✅ Already mounted at $MOUNT_POINT" fi
Bind mount shared directories
for dir in "${BIND_MOUNT_TARGETS[@]}"; do SOURCE="$MOUNT_POINT$HOME_ROOT/$dir" TARGET="$HOME_ROOT/$dir"
if [ -d "$SOURCE" ]; then
# Create target dir if missing
[ -d "$TARGET" ] || mkdir -p "$TARGET"
# Bind mount
echo "🔗 Bind mounting $SOURCE → $TARGET"
sudo mount --bind "$SOURCE" "$TARGET"
else
echo "⚠️ Source directory $SOURCE does not exist — skipping."
fi
done
echo "🚀 Starting xrdp..." sudo systemctl start xrdp
echo "🚀 Starting resticprofile timers..." systemctl --user daemon-reexec systemctl --user daemon-reload systemctl --user enable --now @.*** systemctl --user enable --now @.***
On Sep 2, 2025, at 8:52 AM, Fred @.***> wrote:
creativeprojects left a comment (creativeprojects/resticprofile#558) https://github.com/creativeprojects/resticprofile/issues/558#issuecomment-3245911395 Cool, good to know!
What are you using for encrypting your home? Would it make sense to document your fix, or is it very much home-made?
— Reply to this email directly, view it on GitHub https://github.com/creativeprojects/resticprofile/issues/558#issuecomment-3245911395, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQNZDVCBUDM2EVUDIYLGBT3QW4M7AVCNFSM6AAAAACFIO4CEGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENBVHEYTCMZZGU. You are receiving this because you authored the thread.