Warum lokale Backups auf Shared Hosting mehr als nur ein Nice-to-have sind
Shared Hosting wird oft als günstige Einstiegsoption geschätzt, doch die Backuplösungen der Provider sind nicht immer verlässlich oder gut dokumentiert. Wer hier ausschließlich auf den Anbieter setzt, riskiert im Notfall Datenverluste oder lange Ausfallzeiten.
Viele Webmaster und Agenturen wollen kein teures Managed Backup, stehen aber vor der Frage: Wie sichert man Dateien und Datenbanken automatisiert, sicher und mit minimalem Aufwand? Die Antwort liegt in einfachen, selbstgemachten Lösungen, die lokale Kopien erstellen und so vor bösen Überraschungen schützen.
Automatisierte Backups mit PHP: Datenbanken und Dateien sichern
PHP-Scripts sind ein bewährter Weg, Backups direkt auf dem Server zu erstellen. Das klappt auch auf Shared Hosting, solange PHP-Zugriff und Shell-Befehle nicht zu stark eingeschränkt sind.
Für MySQL-Datenbanken eignet sich das bewährte Tool mysqldump, das man via PHP-Exec-Befehl aufrufen kann. Das Script lässt sich per Cronjob täglich oder stündlich starten, je nach Bedarf:
Code:
<?php
$backupFile = '/home/user/backups/db_backup_' . date('Y-m-d_H-i') . '.sql';
$command = "mysqldump -u dbuser -p'passwort' datenbankname > $backupFile";
exec($command, $output, $return_var);
if ($return_var !== 0) {
error_log('Backup fehlgeschlagen: ' . implode("\n", $output));
}
?>Dateien und Verzeichnisse lassen sich einfach als ZIP archivieren:
Code:
<?php
$backupZip = '/home/user/backups/files_backup_' . date('Y-m-d_H-i') . '.zip';
$zip = new ZipArchive();
if ($zip->open($backupZip, ZipArchive::CREATE) === TRUE) {
$dir = '/home/user/public_html';
$files = new RecursiveIteratorIterator(new RecursiveDirectoryIterator($dir));
foreach ($files as $file) {
if (!$file->isDir()) {
$filePath = $file->getRealPath();
$relativePath = substr($filePath, strlen($dir) + 1);
$zip->addFile($filePath, $relativePath);
}
}
$zip->close();
} else {
error_log('Backup ZIP konnte nicht erstellt werden');
}
?>Viele Hoster erlauben Cronjobs, um diese Scripte ohne manuelles Eingreifen regelmäßig auszuführen. So entstehen kontinuierlich aktuelle Backups.
Sichere Übertragung und externe Ablage: FTP, SFTP oder SSH nutzen
Backups nur auf dem Shared Hosting zu lagern, reicht nicht aus. Die Gefahr: Account gehackt, Server defekt oder versehentliches Löschen.
Deshalb empfiehlt sich die Übertragung auf einen anderen Server, NAS oder lokalen Rechner. FTP ist oft verfügbar, aber unsicher, da Daten unverschlüsselt übertragen werden. Besser ist SFTP oder SSH, sofern der Hoster dies zulässt.
Ein praktisches Beispiel:
- Man erstellt Backups per PHP, wie oben beschrieben.
- Direkt im PHP-Script oder per externem Cronjob kann ein Upload via SFTP automatisiert werden.
PHP-Librarys wie phpseclib bieten einfache Kommandozeilen-SFTP-Funktionen:
Code:
<?php
use phpseclib3\Net\SFTP;
$sftp = new SFTP('zielserver.example.com');
if (!$sftp->login('user', 'passwort')) {
error_log('SFTP Login fehlgeschlagen');
exit;
}
$sftp->put('backups/db_backup.sql', '/home/user/backups/db_backup.sql', SFTP::SOURCE_LOCAL_FILE);
?>Alternativ kann man in der Shell auf dem Server mit scp oder rsync arbeiten, falls SSH-Zugang möglich ist.
Versionskontrolle für Backups? Wann es Sinn macht und wann nicht
Manche Entwickler setzen auf Git oder andere Versionskontrollsysteme, um Änderungen von Dateien im Griff zu behalten. Für größere Webprojekte kann das helfen, aber als Backup ist Git nur begrenzt geeignet:
- Datenbanken lassen sich nicht direkt mit Git sichern.
- Binärdateien (z.B. Medien) blähen das Repository auf.
- Git speichert keine Backups, sondern Versionen – bei versehentlichem Löschen hilft es nur bedingt.
Für reine Codebasis oder Konfigurationsdateien ist Git sinnvoll. Für Backups von Live-Datenbanken und Mediendateien sind automatisierte ZIP-Archive plus externe Speicherung meist praktikabler.
Wiederherstellung im Fehlerfall: Was tun, wenn es brennt?
Ein Backup ist nur so gut wie die Wiederherstellung. Daher gehört ein klarer Plan dazu:
- Datenbank-Backups lassen sich via phpMyAdmin oder MySQL-CLI importieren.
- ZIP-Archive entpackt man per FTP oder SSH in den Webspace.
- Wichtig ist, vor dem Einspielen ein frisches Backup des aktuellen Zustands zu machen – falls Fehler auftreten.
Im Shared Hosting empfehlen sich regelmäßige Probe-Restores, um sicherzugehen, dass Backups vollständig und intakt sind. Nur so vermeidet man böse Überraschungen im Ernstfall.
Meine Einschätzung aus der Praxis
Ich sehe oft, wie Agenturen und Webmaster auf Shared Hosting setzen und erst dann aktiv werden, wenn Daten verloren sind. Automatisierte Backups mit einfachen PHP-Scripts und Cronjobs sind keine Zauberei, sondern Pflicht, wenn kein Managed Backup gebucht wird.
Der größte Stolperstein ist die externe Ablage und regelmäßige Kontrolle der Backups. Ohne SFTP oder SSH wird es schwierig, Backups sicher auszulagern. FTP alleine ist zu unsicher und wird 2026 von den meisten professionellen Hostern ohnehin kaum noch angeboten.
Daher gilt: Wer Shared Hosting nutzt, sollte bei der Auswahl des Providers auf SFTP- oder SSH-Zugriff achten – auch Backup-Strategien hängen davon ab.
Fazit
• Automatisierte Backups per PHP und Cronjobs sind auf Shared Hosting machbar und unerlässlich.
• Datenbanken sichert man per mysqldump, Dateien per ZIP-Archiv.
• Externe Ablage über SFTP oder SSH schützt vor Datenverlust durch Provider-Ausfälle oder Hackerangriffe.
• Versionskontrolle ergänzt Backups für Code, ersetzt sie aber nicht.
• Wiederherstellung muss geübt und geplant sein, um im Ernstfall schnell reagieren zu können.
Wer diese Basics umsetzt, hat eine solide Backup-Strategie - auch ohne teures Managed Backup.
Weiterführend in dieser Serie
Für tieferen Einblick in PHP 8.4 Features und praktische Sicherheitschecks lohnt sich ein Blick in bereits veröffentlichte Artikel:
- PHP 8.4: Neue Stolpersteine, neue Chancen – was jetzt ansteht
- PHP-Altprojekte absichern: OWASP-Check für SQL-Injection, XSS und Session-Fixation
bye
mo