From 7ee7df68ee9d190932e1a260d13555f0d849b0bb Mon Sep 17 00:00:00 2001 From: jared Date: Fri, 5 Jun 2026 11:47:03 -0400 Subject: [PATCH] fix(backup): correct Synology SFTP path and remove pre-flight check MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit SFTP uses a virtual root where Synology shared folders appear directly under / — /volume1/... does not exist in SFTP space. The repo lives at /homes/jared/Backups/fedora-workstation, not /home/Backups/... . Also removes the pre-flight reachability check (HTTP curl, previously SSH) that has been the source of every Synology skip since May 24. Restic handles unreachable SFTP endpoints gracefully; no gate needed. Co-Authored-By: Claude Sonnet 4.6 --- docs/synology.md | 56 +++++++++++++++++++++++------------------------ scripts/backup.sh | 15 +++---------- 2 files changed, 31 insertions(+), 40 deletions(-) diff --git a/docs/synology.md b/docs/synology.md index 773efdf..d1a6817 100644 --- a/docs/synology.md +++ b/docs/synology.md @@ -25,23 +25,31 @@ uid=1026(jared) gid=100(users) groups=100(users),101(administrators),65536(famil ## Volume Paths -Synology shared folders are mounted under `/volume1` over SSH. +**SSH and SFTP use completely different namespaces.** Do not mix them up. -Important paths: +**SSH shell** (`ssh synology`): home is `/var/services/homes/jared` (symlink to `/volume1/homes/jared`). Volume-level paths like `/volume1/...` are accessible. + +**SFTP / restic**: shared folders appear directly under `/` as a virtual root. `/volume1` does not exist in SFTP space. + +```bash +# SFTP root listing +sftp synology <<'EOF' +ls / +EOF +# → archive backup home homes music proxmox_backup +``` + +Active restic repo (SFTP path): + +| Purpose | SFTP path | +| --- | --- | +| Fedora restic repo | `/homes/jared/Backups/fedora-workstation` | + +Active restic repo (SSH path, for manual inspection): | Purpose | SSH path | | --- | --- | -| Main backup share | `/volume1/backup` | -| Fedora continuous restic repo | `/volume1/backup/fedora_desktop_backup_continuous` | -| Older May 2024 user backup | `/volume1/backup/jared_backup052124` | -| Older May 2024 Fedora backup | `/volume1/backup/fedora_backup052124` | -| October 2024 Fedora recovery folder | `/volume1/backup/fedora_recovery_oct2024` | - -List likely backup folders: - -```bash -ssh synology 'find /volume1/backup -maxdepth 2 -mindepth 1 -type d | sort' -``` +| Fedora restic repo | `~/Backups/fedora-workstation` = `/volume1/homes/jared/Backups/fedora-workstation` | ## Restic Access @@ -54,20 +62,16 @@ source ~/.credentials restic -r "sftp:${SYNOLOGY_HOST}:${SYNOLOGY_PATH}" snapshots --compact ``` -As of 2026-05-14, `~/.credentials` has: +As of 2026-06-05, `~/.credentials` has: ```text SYNOLOGY_HOST=synology -SYNOLOGY_PATH=/home/Backups/fedora-workstation +SYNOLOGY_PATH=/homes/jared/Backups/fedora-workstation ``` -Note: that SFTP path is a virtual path for restic/SFTP access. Over an interactive SSH shell, the same repository is visible at: +The leading path segment `homes` is the Synology shared folder name (visible in DSM), not a filesystem path. `/volume1/homes/...` is the SSH/filesystem equivalent but does not exist in SFTP space. -```text -/volume1/backup/fedora_desktop_backup_continuous -``` - -Repository structure confirmed on 2026-05-14: +Repository structure: ```text config @@ -111,15 +115,11 @@ restic -r "sftp:${SYNOLOGY_HOST}:${SYNOLOGY_PATH}" restore latest \ --include /home/jared/path/to/file ``` -## Snapshot State on 2026-05-14 +## Snapshot State on 2026-06-05 -The Fedora continuous repo is accessible and decrypts successfully. It had 17 snapshots from 2026-04-11 through 2026-05-11. +The Fedora restic repo was stalled since 2026-05-24 due to wrong SFTP path in `~/.credentials` (`/home/...` instead of `/homes/...`). Fixed 2026-06-05. Manual backup run confirmed new snapshot saved. Two stale locks were also cleared before the run. -Latest snapshot observed: - -```text -c4ec0c91 2026-05-11 01:58:03 host=fedora tag=fedora size=18.779 GiB -``` +Prior to fix, B2 had been running successfully every night; only Synology was affected. ## SSH Key Recovery Findings diff --git a/scripts/backup.sh b/scripts/backup.sh index 1d91bd9..a861bed 100755 --- a/scripts/backup.sh +++ b/scripts/backup.sh @@ -60,18 +60,9 @@ run_and_notify() { echo "=== Backup started $(date) ===" | tee -a "$LOG" -# Synology: attempt only if reachable (SSH key auth, 30s timeout for HDD spin-up) -if ssh -o ConnectTimeout=30 -o BatchMode=yes synology 'ls /volume1/backup > /dev/null 2>&1' 2>/dev/null; then - run_and_notify "sftp:${SYNOLOGY_HOST}:${SYNOLOGY_PATH}" "Synology" "desktop" "synology" -else - echo "Synology unreachable — skipping SFTP backup" | tee -a "$LOG" - notify_backup.rb \ - --machine desktop \ - --destination synology \ - --status skipped \ - --log-path "$LOG" \ - --notes "Synology unreachable at $(date)" || true -fi +# Synology SFTP: attempt directly — restic fails fast if unreachable, no pre-flight needed +restic -r "sftp:${SYNOLOGY_HOST}:${SYNOLOGY_PATH}" unlock 2>&1 | tee -a "$LOG" || true +run_and_notify "sftp:${SYNOLOGY_HOST}:${SYNOLOGY_PATH}" "Synology" "desktop" "synology" || true # B2: clear any stale lock before attempting (safe no-op if no lock exists) restic -r "b2:${B2_BUCKET}:" unlock 2>&1 | tee -a "$LOG" || true