file_backup.sh

Bash-Script zur Sicherung konfigurierter Verzeichnisse als komprimierte tar.gz-Archive mit automatischer Rotation.

Voraussetzungen

• /backup muss als Dateisystem eingehängt (gemountet) sein
• Benutzer, der das Script ausführt, muss Schreibrechte auf BASEDIR und LOGDIR haben
• numfmt (Paket coreutils) für lesbare Größenausgabe im Log

Verwendung

file_backup.sh [--debug]
file_backup.sh --help
file_backup.sh --version

Parameter	Beschreibung
--debug	Aktiviert ausführliche Ausgaben auf der Konsole
--help	Zeigt Verwendungshinweis und konfigurierte Dirs
--version	Gibt Scriptname und Versionsnummer aus

Die Logdatei wird unter $LOGDIR/file_backup.log geschrieben.

Konfigurationsdatei

Pfad: /usr/local/etc/file_backup.conf

chmod 600 /usr/local/etc/file_backup.conf
chown root:root /usr/local/etc/file_backup.conf

Variablen

Variable	Pflicht	Standard	Beschreibung	Beispiel
BACKUP_DIRS	Ja	—	Bash-Array der zu sichernden Quellverzeichnisse	siehe unten
BASEDIR	Ja	—	Basisverzeichnis für Backups (ohne trailing /)	BASEDIR=/backup/myhostname
LOGDIR	Ja	—	Verzeichnis für Logdateien	LOGDIR=/usr/local/logs
RETENTION	Nein	7	Anzahl aufzubewahrender Generationen pro Verzeichnis	RETENTION=14
EXCLUDE_PATTERNS	Nein	leer	Bash-Array mit Mustern die vom Backup ausgeschlossen werden (tar --exclude)	siehe unten

Beispiel-Konfigurationsdatei

# /usr/local/etc/file_backup.conf

# Zu sichernde Verzeichnisse
BACKUP_DIRS=(
    /etc
    /usr/local/etc
    /home
    /var/lib/grafana
)

# Anzahl aufzubewahrender Generationen pro Verzeichnis
RETENTION=7

# Muster die vom Backup ausgeschlossen werden (tar --exclude)
EXCLUDE_PATTERNS=(
    ".vscode-server"
    ".cache"
    "*.tmp"
    "node_modules"
    "rpm"
)

# Verzeichnisse
BASEDIR=/backup/myhostname
LOGDIR=/usr/local/logs

Verzeichnisstruktur

Das Script legt folgende Struktur unterhalb von BASEDIR an:

$BASEDIR/
└── system/
    ├── etc_20260322_140000.tar.gz
    ├── etc_20260321_140000.tar.gz       # ältere Generationen
    ├── home_20260322_140000.tar.gz
    ├── home_20260321_140000.tar.gz
    └── file_backup.stat               # Statusdatei für Monitoring

Der Archivname wird aus dem Quellpfad abgeleitet (/ wird durch _ ersetzt), ergänzt um einen Timestamp (YYYYMMDD_HHMMSS).

Rotation

Überschreitet die Anzahl der Archive für ein Verzeichnis den Wert RETENTION, werden die ältesten Archive automatisch gelöscht. Jedes Quellverzeichnis hat seine eigene unabhängige Zählkette.

Statusdatei

Die Statusdatei (file_backup.stat) enthält semicolon-getrennte Werte für externes Monitoring:

starttime;RC;description;endtime;duration;lastbackupok;backupsize

Feld	Beschreibung
starttime	Unix-Timestamp: Startzeit des Backups
RC	Return Code (0 = OK, 1 = Fehler, 9 = läuft)
description	Statusbeschreibung im Klartext
endtime	Unix-Timestamp: Endzeit des Backups
duration	Laufzeit in Sekunden
lastbackupok	Unix-Timestamp: letztes erfolgreiches Backup
backupsize	Gesamtgröße des Backup-Verzeichnisses in Bytes

Changelog

Version	Datum	Beschreibung
1.0	22.03.2026	Erste Version

---

influxdb_backup.sh

Bash-Script zur Sicherung einzelner InfluxDB 1.x Datenbanken mittels influxd backup.

Voraussetzungen

• InfluxDB 1.x mit aktivierter HTTP-API und Authentifizierung
• /backup muss als Dateisystem eingehängt (gemountet) sein
• Benutzer, der das Script ausführt, muss Schreibrechte auf BASEDIR und LOGDIR haben

Verwendung

influxdb_backup.sh <DATABASE> [--debug]
influxdb_backup.sh --help
influxdb_backup.sh --version

Parameter	Beschreibung
DATABASE	Name der zu sichernden InfluxDB-Datenbank
--debug	Aktiviert ausführliche Ausgaben auf der Konsole
--help	Zeigt Verwendungshinweis und verfügbare Datenbanken
--version	Gibt Scriptname und Versionsnummer aus

Die Logdatei wird unter $LOGDIR/influxdb_backup.log geschrieben.

Konfigurationsdatei

Pfad: /usr/local/etc/influxdb_backup.conf

Die Konfigurationsdatei wird beim Scriptstart automatisch eingelesen (source).

Sicherheitshinweis: Die Datei enthält das InfluxDB-Passwort und darf nur für root lesbar sein.

chmod 600 /usr/local/etc/influxdb_backup.conf
chown root:root /usr/local/etc/influxdb_backup.conf

Variablen

Variable	Pflicht	Beschreibung	Beispiel
USER	Ja	InfluxDB-Benutzername (alternativ: INFLUX_USER)	USER=backup
INFLUX_USER	Nein	InfluxDB-Benutzername (überschreibt USER)	INFLUX_USER=backup
PW	Ja	InfluxDB-Passwort, base64-kodiert	PW=eEM2N1hFdXFlU3E2WHd2T2VIZ3M=
BASEDIR	Ja	Basisverzeichnis für Backups (ohne trailing /)	BASEDIR=/backup/myhostname
LOGDIR	Ja	Verzeichnis für Logdateien	LOGDIR=/usr/local/logs

Beispiel-Konfigurationsdatei

# /usr/local/etc/influxdb_backup.conf

# InfluxDB-Zugangsdaten
USER=backup
PW=TWVpblBhc3N3b3J0   # base64-kodiertes Passwort

# Verzeichnisse
BASEDIR=/backup/myhostname
LOGDIR=/usr/local/logs

Passwort base64 kodieren

echo -n 'MeinPasswort' | base64

Verzeichnisstruktur

Das Script legt folgende Struktur unterhalb von BASEDIR an:

$BASEDIR/
└── influxdb/
    ├── <DATABASE>/          # aktuelles Backup
    ├── <DATABASE>.old/      # vorheriges Backup (Rolling Backup)
    └── <DATABASE>.stat      # Statusdatei für Monitoring

Statusdatei

Die Statusdatei (<DATABASE>.stat) enthält semicolon-getrennte Werte für externes Monitoring:

starttime;RC;description;endtime;duration;lastbackupok;backupsize;lastflashbackok

Feld	Beschreibung
starttime	Unix-Timestamp: Startzeit des Backups
RC	Return Code (0 = OK, 1 = Fehler, 5 = Warnungen, 9 = läuft)
description	Statusbeschreibung im Klartext
endtime	Unix-Timestamp: Endzeit des Backups
duration	Laufzeit in Sekunden
lastbackupok	Unix-Timestamp: letztes erfolgreiches Backup
backupsize	Größe des Backup-Verzeichnisses in Bytes
lastflashbackok	Unix-Timestamp: letzter erfolgreicher Flashback

Changelog

Version	Datum	Beschreibung
1.0	22.03.2026	Erste Version
2.0	22.03.2026	Refactoring: Config-File, Security Hardening, Best Practices, Error Handling

---

splunkforwarder_update.sh

Aktualisiert den installierten Splunk Universal Forwarder auf die neueste verfügbare Version aus dem konfigurierten Paket-Repository.

Voraussetzungen

• Splunk Universal Forwarder ist unter /opt/splunkforwarder installiert
• Der Benutzer splunkfwd kann den Splunk-Befehl ausführen
• curl und jq sind installiert
• Für RPM-Systeme: dnf
• Für DEB-Systeme: apt
• Der Dienst SplunkForwarder.service ist durch systemd verwaltet
• Das Skript wird mit ausreichenden Rechten für Paketinstallation und Dienstneustart ausgeführt

Verwendung

splunkforwarder_update.sh [--debug]
splunkforwarder_update.sh --help
splunkforwarder_update.sh --version

Parameter	Beschreibung
--debug	Schreibt zusätzlich DEBUG-Meldungen auf stderr
--help	Zeigt Verwendung und verfügbare Optionen
--version	Zeigt Scriptname und Scriptversion

Logging

Alle Betriebs- und Fehlermeldungen werden in folgende Logdatei geschrieben:

/usr/local/logs/splunkforwarder_update.log

Das Logverzeichnis wird beim Start angelegt, wenn es noch nicht existiert. Mit --debug werden Meldungen zusätzlich auf stderr ausgegeben und DEBUG-Meldungen ebenfalls in die Logdatei geschrieben.

Optionale Umgebungsvariablen

Variable	Standardwert	Beschreibung
LOGDIR	/usr/local/logs	Verzeichnis für die Logdatei
BASEURL	https://splunk.jh1.at/splunk-repo	Paket-Repository
SPLUNK_USER	splunkfwd	Benutzer der Splunk-Installation
SPLUNK_BIN	/opt/splunkforwarder/bin/splunk	Pfad zum Splunk-Binary
SERVICE_NAME	SplunkForwarder.service	Name des systemd-Dienstes

Die Logdatei wird unter $LOGDIR/splunkforwarder_update.log geschrieben.

Beispiel für ein alternatives Repository:

BASEURL=https://repo.example.org/splunk LOGDIR=/var/log/splunk \
        ./splunkforwarder_update.sh --debug

Ablauf und Prüfung

Das Skript ermittelt zunächst die installierte Version und erkennt Paketformat und Architektur automatisch. Danach wird der neueste passende Paketname aus $BASEURL/index.py gelesen.

Wenn bereits die neueste Version installiert ist, beendet sich das Skript ohne Installation und ohne Neustart mit Exit-Code 0.

Nach einer Installation wird der Dienst neu gestartet. Der Lauf gilt nur dann als erfolgreich, wenn beide Prüfungen erfüllt sind:

1. SplunkForwarder.service ist nach dem Neustart aktiv.
2. Die laufende Splunk-Forwarder-Version entspricht der Zielversion des neuen Pakets.

Bei einem Fehler wird ein Exit-Code ungleich 0 zurückgegeben und die Ursache im Log vermerkt.

Changelog

Version	Datum	Beschreibung
1.0	18.08.2026	Erste Version
2.0	19.08.2026	Refactoring: Config-File, Security Hardening, Best Practices, Error Handling

---