Diese Anleitung richtet sich an Betreiber eines selbst gehosteten Hermes Agent, die das Linux-Konto und das private GitHub-Repository verwalten können. Das Ziel ist konkret: ein vollständiges Archiv der Hermes-Nutzerdaten, vor Verlassen des Rechners verschlüsselt, am vorgesehenen privaten Remote bestätigt und auf einem separaten Wegwerfrechner abgerufen und importiert. Das dokumentierte Verfahren gilt für die Hermes-CLI beim Commit 86fa9e6, geprüft am 19. Oktober 2026. BIG CHANGE prüfte Shell-Syntax und Kontrollfluss mit inerten lokalen Testdaten; ein echtes Hermes-Backup, age-Verschlüsselung, GitHub-Push, geplanter Start oder Restore wurden nicht ausgeführt. Betrachten Sie das Backup erst als für Ihre Installation belegt, wenn Sie alle folgenden Prüfungen selbst durchgeführt haben.

Die große Veränderung

  • Was sich geändert hat: Der vollständige Backup-Befehl von Hermes kann Arbeitsdaten in einem ZIP sammeln; der Cron-Modus ohne Agent kann ein geprüftes Skript ausführen. Zusammen ermöglichen sie eine geplante verschlüsselte Kopie, ohne ein KI-Modell mit dem Backup zu beauftragen.
  • Warum das wichtig ist: Der Betreiber prüft drei getrennte Fakten: Hermes hat das Archiv fertiggestellt, die verschlüsselten Daten sind im vorgesehenen privaten Repository angekommen und eine frische Installation kann sie importieren. Jede Prüfung erkennt eine andere Fehlerart. Anwendung und einige rechnergebundene Daten fehlen weiterhin im Archiv.
  • Worauf zu achten ist: Entscheidend ist, ob Archiv und wachsender Git-Verlauf klein genug für diesen begrenzten Weg bleiben. Eine gescheiterte Wiederherstellungsübung oder eine der Größengrenzen erfordert einen anderen Speicherplan, bevor Sie sich auf den Zeitplan verlassen.

1. Rechner, Schlüssel und Repository vorbereiten

Verwenden Sie Linux mit Bash, GNU stat -c und du -sb sowie installierter Hermes-CLI, Git, GitHub CLI (gh), age, unzip, sha256sum, SSH und einem aktiven Hermes-Gateway für Cron. Prüfen Sie, ob die installierten Befehle hermes backup, hermes import und hermes cron create --help der festgeschriebenen CLI-Referenz, den FAQ und dem Cron-Handbuch entsprechen. Ermitteln Sie den Betriebssystembenutzer und das HERMES_HOME des Gateways. Führen Sie die gesamte Einrichtung und das erste manuelle Backup als dieser Benutzer aus. Das Beispiel setzt einen dedizierten sauberen Git-Klon und einen main-Branch voraus.

Das vollständige Hermes-Backup enthält Konfiguration, Zugangsdaten, Erinnerungen, Skills, Sitzungen und Profile unter dem Datenstamm. Es lässt Hermes-Code, heruntergeladene Abhängigkeiten und Laufzeiten, frühere Backups, Checkpoints, Browser-Zugangsdatenprofile, SQLite-Begleitdateien und einige lokale Dateien aus. Andere Dateien außerhalb dieses Bereichs werden nicht gesammelt. Verwenden Sie --quick nicht für dieses vollständige Datenbackup. Prüfen und schützen Sie wichtige Daten außerhalb dieses Bereichs separat. Das ZIP enthält Geheimnisse, auch wenn das Ziel-Repository privat ist.

Erzeugen Sie eine age-Identität, den privaten Entschlüsselungsschlüssel, an einem geschützten Ort außerhalb von HERMES_HOME, dem Staging-Verzeichnis und dem Git-Klon. Bewahren Sie eine unabhängig gespeicherte Wiederherstellungskopie dieser Identität auf. Der ausgegebene Empfänger age1… ist öffentlich und gehört in die Konfiguration; die private Identität nicht. Folgen Sie der age-Nutzungsreferenz.

Terminal
umask 077
install -d -m 700 /PRIVATE-KEY-STORE
age-keygen -o /PRIVATE-KEY-STORE/hermes-backup-identity.txt
age-keygen -y /PRIVATE-KEY-STORE/hermes-backup-identity.txt

Erstellen Sie ein privates Repository ausschließlich für dieses Backup, prüfen Sie die Zugriffsberechtigten und richten Sie nichtinteraktiven Lesezugriff mit gh und Git-SSH-Schreibzugriff für denselben Betriebssystembenutzer wie Hermes Cron ein. Tokens und private SSH-Schlüssel müssen außerhalb von Hermes-Daten, Staging und Git liegen. Eine interaktive Anmeldung unter einem anderen Konto belegt keinen geplanten Zugriff. Ersetzen Sie die großgeschriebenen Platzhalter vor Ausführung. Hat die Repository-Erstellung bereits ein README oder einen main-Branch angelegt, prüfen Sie dies und überspringen Sie widersprechende Initialisierungsbefehle.

Terminal
gh repo create ACCOUNT/PRIVATE-REPOSITORY --private --clone
gh repo view ACCOUNT/PRIVATE-REPOSITORY --json isPrivate --jq .isPrivate
cd PRIVATE-REPOSITORY
git remote set-url origin git@github.com:ACCOUNT/PRIVATE-REPOSITORY.git
git remote get-url --all origin
git remote get-url --push --all origin
git branch -M main
printf '%s\n' 'Encrypted Hermes backup storage; ciphertext and checksum only.' > README.md
git add README.md
git commit -m 'Initialize private backup repository'
git push -u origin HEAD:main
git ls-remote --heads origin main

gh repo create --clone kann aufgrund lokaler Einstellungen HTTPS wählen; das oben ausdrücklich gesetzte SSH-Remote bestimmt das Ziel dieses Verfahrens. Fahren Sie erst fort, wenn isPrivate den Wert true liefert, die Mitwirkenden beabsichtigt sind, effektive Abruf- und Push-URL jeweils genau der einen geprüften SSH-URL entsprechen und der Remote-Zugriff als geplanter Benutzer funktioniert. Die Git-Remote-Regeln erlauben URL-Umschreibungen, zusätzliche Ziele und eine separate pushurl; das folgende Skript prüft bei jedem Lauf rohe und effektive Werte.

Verlassen Sie den Klon, bevor Sie die nächsten beiden Codeblöcke speichern. Erstellen Sie ein privates Einrichtungsverzeichnis außerhalb von Hermes-Datenstamm, Git-Klon, Staging und Schlüsselspeicher. Speichern Sie hermes-github-backup.sh und hermes-github-backup.conf dort; die Installationsbefehle kopieren sie in das besitzende Profil. Der dedizierte Git-Klon muss sauber bleiben.

Terminal
install -d -m 700 /ABSOLUTE/PRIVATE-SETUP
cd /ABSOLUTE/PRIVATE-SETUP

2. Geprüftes Backup-Skript installieren

Speichern Sie den vollständigen folgenden Bash-Block als hermes-github-backup.sh in diesem privaten Einrichtungsverzeichnis. Speichern Sie den zweiten Block als hermes-github-backup.conf daneben und ersetzen Sie alle Platzhalter durch absolute Pfade oder den öffentlichen Empfänger. Diese Shell-Konfiguration muss vor dem Laden lokal geprüft werden und darf nur dem Besitzer zugänglich sein. Sie darf kein Passwort, Token oder private age-Identität enthalten. Das Skript ist der vollständige vorgeschlagene Beispielcode; Syntax und inerter Kontrollfluss wurden geprüft, doch Sie müssen es an Ihre Installation anpassen und testen. Die erzeugte Datei latest.zip.age ist das verschlüsselte Archiv.

Terminal
#!/usr/bin/env bash
# Documentation-based Linux sample for an operator to review and adapt.
# Place with hermes-github-backup.conf under the owning HERMES_HOME/scripts/.
# Requires GNU stat -c and du -sb. Git Bash was used only for inert fixtures.
set -Eeuo pipefail
umask 077

script_dir=$(CDPATH= cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd -P)
owning_home=$(CDPATH= cd -- "$script_dir/.." && pwd -P)
if [[ -n ${HERMES_HOME:-} && $(CDPATH= cd -- "$HERMES_HOME" && pwd -P) != "$owning_home" ]]; then
  printf 'Backup stopped: cron profile and script directory differ.\n' >&2
  exit 1
fi
export HERMES_HOME="$owning_home"

config="$script_dir/hermes-github-backup.conf"
[[ -f "$config" ]] || { printf 'Backup stopped: reviewed configuration missing.\n' >&2; exit 1; }
# This file is local, owner-reviewed shell configuration. It must contain no secret.
# shellcheck source=/dev/null
source "$config"
: "${HERMES_BIN:?set an absolute Hermes executable path}"
: "${REPO_DIR:?set an absolute private clone path}"
: "${STAGING_PARENT:?set an absolute private staging path}"
: "${AGE_RECIPIENT:?set an age public recipient}"
: "${EXPECTED_REMOTE:?set the exact private GitHub SSH remote}"
: "${BRANCH:=main}"

fail() { printf 'Backup stopped: %s.\n' "$1" >&2; exit 1; }
for path in "$HERMES_BIN" "$REPO_DIR" "$STAGING_PARENT"; do
  [[ $path == /* ]] || fail 'a configured path is not absolute'
done
[[ -x "$HERMES_BIN" ]] || fail 'Hermes executable unavailable'
[[ $AGE_RECIPIENT == age1* ]] || fail 'age public recipient invalid'
[[ $EXPECTED_REMOTE == git@github.com:*/*.git ]] || fail 'remote is not the reviewed GitHub SSH URL'
[[ $BRANCH =~ ^[a-zA-Z0-9._/-]+$ ]] || fail 'branch name invalid'
[[ -d "$STAGING_PARENT" ]] || fail 'staging directory unavailable'
stage_parent=$(CDPATH= cd -- "$STAGING_PARENT" && pwd -P)
[[ $stage_parent != "$owning_home" && $stage_parent != "$owning_home"/* ]] || fail 'staging is inside Hermes data'

# Atomic, nonblocking whole-flow lock: keep it through push and remote readback.
# A stale directory after a crash requires operator inspection; never steal it.
lockdir="$stage_parent/.hermes-github-backup-flow.lock"
mkdir -- "$lockdir" 2>/dev/null || fail 'another backup flow holds the lock or a stale lock needs review'
work=''
cleanup() {
  if [[ -n $work ]]; then
    rm -f -- "$work/hermes.zip" "$work/latest.zip.age" "$work/latest.sha256" "$work/backup.log"
    rmdir -- "$work" 2>/dev/null || true
  fi
  rmdir -- "$lockdir" 2>/dev/null || true
}
trap cleanup EXIT

[[ -d "$REPO_DIR/.git" ]] || fail 'Git repository unavailable'
repo=$(CDPATH= cd -- "$REPO_DIR" && pwd -P)
[[ $repo != "$owning_home" && $repo != "$owning_home"/* ]] || fail 'repository is inside Hermes data'
[[ $stage_parent != "$repo" && $stage_parent != "$repo"/* ]] || fail 'staging is inside Git repository'
[[ $repo != "$stage_parent"/* ]] || fail 'Git repository is inside staging'

command -v age >/dev/null || fail 'age unavailable'
command -v gh >/dev/null || fail 'GitHub CLI unavailable for private visibility check'
command -v unzip >/dev/null || fail 'zip verifier unavailable'
command -v git >/dev/null || fail 'Git unavailable'
remote_repo=${EXPECTED_REMOTE#git@github.com:}
remote_repo=${remote_repo%.git}
visibility=$(gh repo view "$remote_repo" --json isPrivate --jq .isPrivate 2>/dev/null) || fail 'GitHub repository visibility unreadable'
[[ $visibility == true ]] || fail 'GitHub repository is not confirmed private'
raw_fetch_urls=$(git -C "$repo" config --get-all remote.origin.url) || fail 'Git fetch URL missing'
[[ $raw_fetch_urls == "$EXPECTED_REMOTE" ]] || fail 'Git has multiple or unexpected raw fetch URLs'
raw_push_urls=$(git -C "$repo" config --get-all remote.origin.pushurl || true)
[[ -z $raw_push_urls ]] || fail 'separate Git pushurl requires independent review'
effective_fetch_urls=$(git -C "$repo" remote get-url --all origin) || fail 'effective fetch URL unreadable'
effective_push_urls=$(git -C "$repo" remote get-url --push --all origin) || fail 'effective push URL unreadable'
[[ $effective_fetch_urls == "$EXPECTED_REMOTE" ]] || fail 'Git fetch URL rewrite or extra destination'
[[ $effective_push_urls == "$EXPECTED_REMOTE" ]] || fail 'Git push URL rewrite or extra destination'
[[ $(git -C "$repo" branch --show-current) == "$BRANCH" ]] || fail 'local branch changed'
[[ -z $(git -C "$repo" status --porcelain --untracked-files=all) ]] || fail 'repository has unrelated changes'

# No interactive prompt is possible in an unattended Hermes cron tick.
export GIT_TERMINAL_PROMPT=0
export GIT_SSH_COMMAND='ssh -o BatchMode=yes'
remote_head=$(git -C "$repo" ls-remote --heads origin "$BRANCH" | awk '{print $1}')
[[ -n $remote_head && $remote_head == "$(git -C "$repo" rev-parse HEAD)" ]] || fail 'remote unreadable or branch has changed'

work=$(mktemp -d "$stage_parent/hermes-backup.XXXXXXXX") || fail 'private staging creation failed'

if "$HERMES_BIN" backup -o "$work/hermes.zip" >"$work/backup.log" 2>&1; then
  :
else
  backup_rc=$?
  fail "Hermes full backup returned $backup_rc; temporary zip/log will be removed, so diagnose with a separate controlled manual run"
fi
[[ -s "$work/hermes.zip" ]] || fail 'Hermes archive absent or empty'
unzip -tq "$work/hermes.zip" >"$work/backup.log" 2>&1 || fail 'zip integrity check failed'
age -r "$AGE_RECIPIENT" -o "$work/latest.zip.age" "$work/hermes.zip" >"$work/backup.log" 2>&1 || fail 'archive encryption failed'
[[ -s "$work/latest.zip.age" ]] || fail 'encrypted archive absent or empty'

# Deliberately below GitHub's 50 MiB warning. Git history retains every version.
cipher_bytes=$(stat -c %s "$work/latest.zip.age")
(( cipher_bytes <= 40000000 )) || fail 'encrypted archive exceeds this small-repository recipe'
git_bytes=$(du -sb "$repo/.git" | awk '{print $1}')
(( git_bytes + cipher_bytes + 10000000 <= 500000000 )) || fail 'repository history approaches the review limit'
hash=$(sha256sum "$work/latest.zip.age" | awk '{print $1}')
printf '%s  latest.zip.age\n' "$hash" >"$work/latest.sha256"

cp -- "$work/latest.zip.age" "$repo/latest.zip.age"
cp -- "$work/latest.sha256" "$repo/latest.sha256"
git -C "$repo" add -- latest.zip.age latest.sha256
staged=$(git -C "$repo" diff --cached --name-only)
[[ $staged == $'latest.sha256\nlatest.zip.age' ]] || fail 'staged paths are not the two reviewed files'
git -C "$repo" diff --cached --check >/dev/null || fail 'staged content check failed'
git -C "$repo" commit -m "Encrypted Hermes backup $(date -u +%Y-%m-%dT%H:%M:%SZ)" >/dev/null || fail 'local backup commit failed'
run_head=$(git -C "$repo" rev-parse HEAD)
(( $(du -sb "$repo/.git" | awk '{print $1}') <= 500000000 )) || fail 'Git history exceeds review limit before push'
[[ $(git -C "$repo" rev-parse HEAD) == "$run_head" ]] || fail 'local HEAD changed before push'
git -C "$repo" push origin "$run_head:refs/heads/$BRANCH" >/dev/null || fail 'remote push failed; inspect exact remote before retrying'
remote_head=$(git -C "$repo" ls-remote --heads origin "$BRANCH" | awk '{print $1}')
[[ $remote_head == "$run_head" ]] || fail 'this run commit not confirmed at remote'
printf 'Encrypted backup verified at private remote commit %s.\n' "$run_head"
Terminal
# No passwords, tokens, age identities or private keys belong here.
HERMES_BIN=/absolute/path/to/hermes
REPO_DIR=/absolute/path/to/dedicated-private-github-clone
STAGING_PARENT=/absolute/path/to/private-staging-outside-hermes-and-git
AGE_RECIPIENT=age1replace_with_operator_public_recipient
EXPECTED_REMOTE=git@github.com:ACCOUNT/PRIVATE-REPOSITORY.git
BRANCH=main

Erstellen Sie Staging außerhalb von Hermes-Datenstamm und Git-Klon. Legen Sie die geprüften Dateien im Verzeichnis scripts/ des besitzenden Profils ab. Der Klon muss vor jedem Lauf sauber und auf den Remote-Branch main ausgerichtet sein. Das Skript sperrt den gesamten Ablauf bis zu Push und Rückprüfung; es übernimmt nie eine gehaltene oder alte Sperre. Als neu zum Commit vorgemerkte Backuppfade akzeptiert es nur latest.zip.age und latest.sha256. Es stoppt, wenn die verschlüsselte Datei 40.000.000 Bytes überschreitet oder das lokale .git zuzüglich Reserve an 500.000.000 Bytes heranreicht. Dies sind vorsichtige Grenzen dieses Beispiels, keine GitHub-Speichergarantien.

Terminal
export HERMES_HOME=/absolute/path/to/owning-hermes-data-root
install -d -m 700 /ABSOLUTE/PRIVATE-STAGING
install -d -m 700 "$HERMES_HOME/scripts"
install -m 700 hermes-github-backup.sh "$HERMES_HOME/scripts/hermes-github-backup.sh"
install -m 600 hermes-github-backup.conf "$HERMES_HOME/scripts/hermes-github-backup.conf"
"$HERMES_HOME/scripts/hermes-github-backup.sh"

Der manuelle Lauf sollte mit Exitcode null enden und den Commit ausgeben, der bei genau diesem Lauf erstellt und anschließend frisch am Remote geprüft wurde. Bestätigen Sie, dass gh repo view weiterhin privat meldet, prüfen Sie die verfolgten Pfade des Klons und den exakten Commit am vorgesehenen Remote. Ein lokales Archiv oder Commit belegt keine externe Sicherung. Ein gestoppter Lauf darf nicht so verbucht werden. Laut Hermes liefert ein vollständiges Backup 0 nur, wenn alle gewählten Dateien hinzugefügt wurden, 1 bei unvollständigem Archiv, selbst wenn ein ZIP existiert, und 2 bei einem anderen laufenden Backup. Das Skript entfernt temporäres ZIP und Protokoll beim Beenden; normales Löschen ist kein sicheres Löschen. Untersuchen Sie übersprungene Dateien mit einem separaten kontrollierten manuellen hermes backup -o /PRIVATE-DIAGNOSTIC/hermes.zip, prüfen Sie Exitcode und Bericht und entscheiden Sie über den Schutz ausgelassener Daten.

3. Planen und ersten fälligen Lauf prüfen

Verwenden Sie erst nach dem manuellen Ergebnis den dokumentierten Hermes-Modus --no-agent --script aus demselben Profil. Er führt eine Datei ohne LLM-Aufruf aus. Wählen Sie bewusst eine Frequenz und lokale Statusausgabe ohne Geheimnisse. Prüfen Sie Gateway-Benutzer, Profil und nächste Fälligkeit. Laut Hermes wird das Skript-Zeitlimit aus HERMES_CRON_SCRIPT_TIMEOUT, danach aus cron.script_timeout_seconds und schließlich aus einem Standardwert von 3.600 Sekunden bestimmt. Setzen und prüfen Sie einen zu einem beobachteten Lauf passenden Wert; eine Zeitüberschreitung ist ein Fehler. Die bereinigte Skriptumgebung erhält nicht automatisch die von Hermes verwalteten Anbieterzugangsdaten. Prüfen Sie daher unbeaufsichtigten gh- und SSH-Zugriff als tatsächlicher geplanter Benutzer, bevor Sie sich darauf verlassen.

Terminal
hermes cron create '0 3 * * *' --no-agent --script hermes-github-backup.sh --deliver local --name 'Encrypted Hermes backup'
hermes cron list
hermes cron status
hermes cron doctor

Prüfen Sie nach der ersten geplanten Fälligkeit die exakte Job-ID und den Laufdatensatz, die lokale Ausgabe unter ~/.hermes/cron/output/ beim Standardprofil, etwaige Vorfälle und den Head-Commit des vorgesehenen Remotes. Bestätigen Sie, dass das Gateway verfügbar blieb und der Lauf den bei diesem Auslösen erzeugten Remote-Commit meldete. Ein manueller Aufruf belegt keinen Cron-Lauf. Fehlende Ausgabe verlangt eine Prüfung dieses Jobs und Gateways, keinen zweiten Zeitplan. Statusmeldungen dürfen keine ZIP-Inhalte, Geheimnisse oder Zugangsdaten enthalten.

4. Abruf und Import auf frischem Rechner belegen

Verwenden Sie einen separaten Wegwerf-Linux-Rechner ohne produktives Hermes-Profil oder Gateway. Installieren Sie dort zuerst eine kompatible Hermes-Version: Das Archiv enthält Nutzerdaten, kein Anwendungs- oder Laufzeitabbild. Geben Sie dem Testrechner unabhängigen autorisierten Lesezugriff auf das vorgesehene private Repository und die unabhängig aufbewahrte age-Identität. Prüfen Sie Remote und gewählten Commit des Klons. Führen Sie hermes import nicht auf dem Quellrechner oder einem vorhandenen Profil aus. Lassen Sie alle wiederhergestellten Zeitpläne und externen Aktionen inaktiv, bis ein Mensch ihre Ziele geprüft und über ihre Aktivierung entschieden hat.

Terminal
umask 077
unset HERMES_HOME
git clone git@github.com:ACCOUNT/PRIVATE-REPOSITORY.git /PRIVATE-RECOVERY/hermes-backup-clone
cd /PRIVATE-RECOVERY/hermes-backup-clone
sha256sum -c latest.sha256
age --decrypt -i /PRIVATE-KEY-STORE/hermes-backup-identity.txt -o /PRIVATE-RECOVERY/hermes.zip latest.zip.age
unzip -tq /PRIVATE-RECOVERY/hermes.zip
hermes import /PRIVATE-RECOVERY/hermes.zip
hermes setup
hermes cron list

Vergleichen Sie importierte Profile, Skills, Erinnerungen, Sitzungen und Cron-Definitionen mit dem beabsichtigten Sicherungsumfang. hermes setup prüft die Anbieterkonfiguration; untersuchen Sie dennoch anzupassende Zugangsdaten und maschinenspezifische Pfade. Dokumentieren Sie tatsächliche Ergebnisse. Eine passende Prüfsumme und ein entschlüsselbares ZIP allein belegen keinen nutzbaren Restore. Entfernen Sie das unverschlüsselte Test-ZIP nach der Übung gemäß lokaler Richtlinie; normales Löschen verspricht kein sicheres Löschen.

Wenn die Prüfungen stoppen

Ein unvollständiges Hermes-Backup, ZIP- oder Verschlüsselungsfehler, unerwartete effektive Git-URL, nicht privates oder unlesbares Repository, gehaltene Ablauf-Sperre, Größengrenze, gescheiterter Push, abweichender Remote-Commit oder gescheiterter Import lässt diesen Lauf unbestätigt. Beheben Sie die konkrete Ursache und prüfen Sie vor einem weiteren Versuch den aktuellen Zustand. Ist das Push-Ergebnis unklar, prüfen Sie zuerst exakten Remote-Branch und Commit. Bleibt nach einem Absturz die Sperre, prüfen Sie lebende Prozesse sowie lokalen und entfernten Zustand; löschen Sie nie eine aktive Sperre. Bei Verlust der privaten age-Identität ist eine unabhängige gültige Kopie zur Entschlüsselung nötig. Rotieren Sie offengelegte Zugangsdaten zuerst, falls Klartextgeheimnisse in Git gelangen; spätere Dateilöschung entfernt weder frühere Historie noch andere Klone.

GitHubs Hinweise zu großen Dateien warnen ab 50 MiB, blockieren normale Git-Dateien über 100 MiB und erklären, dass Git nicht als Backup-Werkzeug ausgelegt ist. Dieses Beispiel stoppt bewusst unter diesen Grenzen. Jede geänderte verschlüsselte Datei bleibt in der Git-Historie, auch wenn latest.zip.age ersetzt wird. Erhöhen Sie die Stopps bei 40 MB/500 MB nicht stillschweigend, schreiben Sie die Historie nicht um und setzen Sie privat nicht mit verschlüsselt gleich. Bewerten Sie bei Größen- oder Wiederherstellungsfehlern einen backupspezifischen Speicher oder separat geprüften LFS-Plan neu. Konto-, Speicher-, Netzwerk- und Hostkosten gelten weiterhin; das Skript ohne Agent selbst benötigt keinen LLM-Aufruf. Dauer, Erfolgsquote oder Einsparung dieses Verfahrens wurden nicht gemessen.

Eine separate, engere Hermes-Planungsaufgabe beschreibt wie Sie einen skillgestützten wiederkehrenden Hermes-Job einrichten und seinen ersten Lauf prüfen. Die Berichtsprüfung dieses Jobs ersetzt kein verschlüsseltes Archiv und keine Wiederherstellungsübung.

Quellen und weiterführende Informationen