Datenerhalt und Fallback

Aktueller Stand 16.10.2026

Verbindlich: main@8fb581b730f7a3833566c4bbb7c87875ad921e69; veröffentlicht bleibt v1.9.0. PR #74–#97 sind integriert. Deployment/Discovery, Imagebuilder, Pi-VPN und Syslog sind auf main, nicht mehr nur historische Vorschau. 26 reguläre Rollen einschließlich Deployment-VM; Provisioning ist optional zusätzlich.

Betreiberbestätigt: KDE-Boot, Rufe, SDS, Aufnahme/RF-Wiedergabe und WLAN am 13.10.; 28/28 Discovery-Agenten aktualisiert und keine ungeklärten Remote-Aufträge mehr am 15.10. Ein aktueller Backend-Gesamtrollout, NAS-Entlastung, SIP/Telegram, VPN-Wechsel und Dauerlauf bleiben separat offen. Vier alte Git-/Timeoutfehler bleiben Fehler.

Gesamtroadmap · Upstream-Vergleich · Roadmap und Releases. NETCORE-IAM-01 ist weiterhin Planung; AD-SSO-Pilot und Gruppenmapping sind konkretisiert, Produkt-/Betriebsentscheidung und Umsetzung offen.

Aktueller Runtime-Updateweg erhält Konfiguration, Units und Nutzdaten und prüft neue Prozesse. NAS-Cachewartung löscht keine Archivdateien; lokale Freigabe braucht privaten Beleg und erneut gelesene gültige NAS-Kopie. Datensicherung und Fallback.

Historischer Seitenstand bis 07.10.2026

Die folgende frühere Fassung bleibt als datierte Historie erhalten. Frühere Dienstzahlen, Featurebranch-Aussagen, offene Tests und Prioritäten sind keine aktuelle Statusaussage; heutige Verfahren stehen oben beziehungsweise in den verlinkten kanonischen Docs.

Backup und Fallback

Aktueller Quellenstand 07.10.2026: main 990bffb2; Release weiterhin v1.9.0. PR #59 mit Hell/Dunkel ist integriert, PR #60 ergänzt Projektarchive. Nur main ist als Branch vorhanden. Deployment/Discovery, Imagebuilder, Pi-VPN und neuere Syslog-Pipeline bleiben ausschließlich am historischen Featurecommit bbf0397 vorhanden. Keine neue Live-Abnahme. Roadmap und Releases · Upstream-Vergleich

Aktueller Updateweg

PR #59 ist auf main; der frühere Branch feat/netcore-dashboard-design existiert nicht mehr. Alte Branchwechsel in den TBS- und Dienstanleitungen durch einen geprüften main-/SHA-Checkout ersetzen. Aktive Unit, ExecStart, Binary- und Konfigurationspfad erfassen; lokale Änderungen, Konfiguration und vorherige Binary sichern. Erst erfolgreich bauen, dann gezielt installieren und Fachfunktion prüfen.

Für das reine TBS-Designupdate MIGRATE_LOCAL_TTS_CONFIG=0 und DISABLE_LOCAL_PIPER=0 verwenden. Dienst-Updater können zusätzliche Konfigurationen verändern; gezielte Binary-/Python-Updates gemäß tatsächlicher Unit bevorzugen. Rückweg über die gesicherte passende Binary und den dokumentierten früheren Quell-SHA, ohne aktuelle Konfiguration pauschal zu überschreiben. Ein Checkout allein aktualisiert keinen installierten Dienst.

Primär- und Fallback-Konfiguration

Kann die angegebene Primärkonfiguration nicht geladen werden, versucht die Basisstation automatisch eine Datei mit angehängtem .fallback:

config.toml
config.toml.fallback

Wird Fallback verwendet, zeigt das Dashboard dauerhaft eine rote Warnung. Das System kann damit weiterlaufen, aber die Ursache der fehlerhaften Primärdatei muss behoben werden.

Dashboard-Sicherung

Vor dem Überschreiben durch den Konfigurationseditor wird zusätzlich eine .bak-Datei erzeugt. Diese ist eine kurzfristige Rückfallebene, ersetzt aber kein externes Backup.

Zu sichernde Daten

• config.toml
• config.toml.fallback
• Konfigurations-.bak
• Directory-SQLite-Datenbank
• Directory-Exportdatei
• TTS-Vorlagen
• lokale Medienbibliothek
• Recovery-Cache
• Systemd-Units und Environment-Dateien
• bei Bedarf Aufzeichnungen und JSON-Metadaten
• im verteilten Aufbau die Persistenzdaten und Konfigurationen aller betroffenen Backend-LXCs
• IoT-Command-Ledger/Outbox, Ruf- und Teilnehmerzustände nach den Dienst-Runbooks
• SIP-/Asterisk-Konfiguration und Trunk-Zugangsdaten, getrennt vom Wiki
• Security-/KMF-Schlüsselmaterial ausschließlich mit dem dafür vorgesehenen geschützten Verfahren

Backup-Beispiel

sudo systemctl stop tetra.service
sudo tar -C / -czf /var/backups/netcore-$(date +%Y%m%d-%H%M%S).tar.gz \
  etc/netcore \
  var/lib/netcore \
  var/lib/netcore-directory
sudo systemctl start tetra.service

Pfade an die reale Installation anpassen. Große Aufnahmeverzeichnisse gegebenenfalls separat sichern.

Wiederherstellung

1. Dienst stoppen.
2. beschädigte Dateien separat wegkopieren.
3. Backup entpacken oder einzelne Dateien wiederherstellen.
4. Eigentümer und Dateirechte prüfen.
5. Basisstation manuell mit der wiederhergestellten Konfiguration starten.
6. erst danach Systemd wieder aktivieren.

Nach einem Fallback-Start

sudo journalctl -u tetra.service -b --no-pager | grep -iE 'config|fallback|parse|error'
diff -u /etc/netcore/config.toml.fallback /etc/netcore/config.toml

Nicht die Fallback-Datei blind über die Primärdatei kopieren. Sie kann bewusst konservativ oder älter sein.

Zentrale Ausfallgrenzen

Der lokale RF-Dienst kann bei einem Backend-Ausfall gemäß [edge_fallback] weiterlaufen. Das bedeutet nicht, dass netzweite Rufe, neue Schlüssel, SIP-Routing oder alle SDS-Zustellungen verfügbar bleiben. Der Zustand der Service-Matrix hat eine Lease; nach Wiederkehr Spool, Acks, Policies und tatsächliche Endgerätefunktion prüfen. Mehrzellenbetrieb · Betrieb-und-Wartung

Eine Datei-Kopie einer SQLite-/Zustandsdatenbank während laufender Schreibzugriffe ist nicht automatisch konsistent. Für jeden Dienst die zugehörige Backup- oder Exportfunktion, Dienststopp beziehungsweise transaktionale Sicherung verwenden. Rücksicherung mit passender Software- und Schema-Version erproben.

Warnungen und historische Git-Stände

Warn-SQLite, SDS-Router-Persistenz, Config und Releasekennung zusammen sichern. SQLite konsistent sichern oder den Dienst für die Kopie geordnet anhalten. Beim Rollback keine Warn-/SDS-Datenbank löschen: Die persistente Duplikatsperre könnte sonst verloren gehen. Datenschema und alter Build müssen kompatibel sein. Warnzentrale

main besitzt seit v1.9.0 eine neu angelegte Historie. Vor dem Wechsel lokale Änderungen und Konfiguration sichern; einen frischen Clone oder expliziten Fetch/Detached-Checkout verwenden. Frühere Stände sind über drei Archiv-Tags erhalten. Roadmap und Releases

Entwicklungsvorschau vom 28 September 2026

Entwicklungsvorschau vom 28.09.2026: Historischer Featurecommit bbf0397, Deployment-Komponente 0.2.3. Diese Funktionen sind noch nicht auf main und kein neuer Gesamtrelease. PR #57 wurde in den Entwicklungsbranch gemergt. Zur Vorschau gehören Original-/Runtime-TOML, Agent-/Controller-SQLite, Quell-SHA, Image-Manifest, Syslog-Cursor und Archive. Konfigurationskopien liegen unter /var/lib/netcore-discovery/backups/. Der Controller ist keine Laufzeitabhängigkeit des Funks; der letzte gute Cache bleibt lokal. Ein pauschaler atomarer Rollback aller Dienste ist nicht belegt. Deployment-und-Discovery · Syslog-und-Archivierung

Stationspakete als Ausbauempfehlung vom 02.10.2026

Bost FlowStation ergänzt bei bb87b84c ZIP-basierte .bptbs-Stations- und .ptbs-Profilpakete. NetCores vorhandener Config-Backup-/Restore-Pfad ist kein gleichwertiger Gesamtstations-Export. Eine Übernahme ist nicht implementiert oder beschlossen. Vor einem Port sind Manifest/Schema, Dateipfade, Geheimnisse, Importvalidierung und konsistente Rücknahme zu klären: Bost-Pakete können WLAN-PSKs enthalten, die ZIP-Kompression verschlüsselt sie nicht; der Import ersetzt Profilverzeichnisse. Zentrale NetCore-Datenbanken und Schlüssel benötigen weiterhin dienstspezifische Sicherungen. Upstream-Vergleich · Projektideen und Entwicklungsstand