jf/syncova-backup
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 9 Wiki Activity

9 Releases 9 Tags

RSS Feed
  • v1.0.0-rc3 a37631c501
    Compare

    Syncova Backups V1 — Release Candidate 3
    Some checks failed
    CI / Backend (Go) (push) Failing after 32s
    Details
    CI / Frontend (React/TypeScript) (push) Successful in 35s
    Details
    CI / Sicherheitsprüfungen (push) Successful in 24s
    Details
    Pre-Release

    jf released this 2026-08-17 14:14:41 +00:00 | 14 commits to main since this release

    Dritter Auslieferungskandidat. Er behebt #1 — die Einrichtung brach ab, wenn das Repository unter /tmp liegen sollte.

    Was passiert war

    Die Diensteinheit setzt PrivateTmp=yes. Der Dienst bekommt damit ein eigenes /tmp; der in ReadWritePaths genannte Ablageort existiert in seiner Sicht nicht, und systemd bricht ab, bevor das Programm überhaupt läuft:

    syncova-api.service: Failed to set up mount namespacing:
    /tmp/syncova-repository: No such file or directory
status=226/NAMESPACE

    Was daran der größere Fehler war

    Nicht der Startfehler, sondern dass setup.sh einen Ablageort unter /tmp überhaupt angenommen hat. systemd-tmpfiles räumt dort regelmäßig auf, und auf einem tmpfs ist nach einem Neustart nichts mehr da. Die Sicherungen wären von selbst verschwunden — ohne Meldung, bis jemand sie braucht.

    Ein Backupsystem, das jede Nacht Erfolg meldet und keine Daten hat, ist schlimmer als gar keines.

    Behoben

    • Flüchtige Ablageorte werden abgelehnt: /tmp, /var/tmp, /dev/shm, /run und jedes tmpfs oder ramfs. Geprüft wird vor der Datenbankeinrichtung — ein unbeaufsichtigter Lauf scheitert damit in Sekunden statt nach Minuten und einem Rückbau.
    • Ausdrückliche Freigabe für Wegwerf-Umgebungen: SYNCOVA_SETUP_ALLOW_VOLATILE_REPOSITORY=ja. Dann wird PrivateTmp abgeschaltet, sonst startete der Dienst nie.
    • Der Abbruch zeigt den Grund. Kommt der Dienst nicht hoch, liefert setup.sh die letzten Journalzeilen gleich mit und erklärt 226/NAMESPACE. Der bloße Verweis auf journalctl war wertlos: Beim Rückbau ist der Dienst weg.

    Regressionstest vorhanden und als fangend geprüft.

    Aktualisieren

    Betrifft nur die Einrichtung; eine laufende Anlage ist nicht betroffen.

    tar -xzf syncova-v1.0.0-rc3-linux-amd64.tar.gz
cd syncova-v1.0.0-rc3-linux-amd64
shasum -a 256 -c SHA256SUMS
sudo ./update.sh          # aus rc1 oder rc2
sudo ./setup.sh           # Neuinstallation

    Unverändert: warum RC und nicht 1.0.0

    Drei Zusagen sind gebaut, aber nie auf echter Hardware gefahren: der Windows-Dienst, die systemd-Einheit des Agenten und der Proxmox-Meilenstein — ob eine wiederhergestellte VM startet, ist ungeprüft.

    Vollständige Liste: CHANGELOG.md · docs/release-candidate.md

    Downloads