Backups · S3 · VPS

So sichern Sie einen VPS auf einem S3 Eimer mit Cipi

Von · Letzte Aktualisierung: · Kostenlose Lektüre, keine Paywall

Ein Dump, der sich auf derselben Festplatte wie die App befindet, ist ein Snapshot und kein Backup. Dieser Leitfaden führt Sie durch die gesamte Off-Site-Schleife mitCipi: Erstellen Sie einen Bucket, speichern Sie die Anmeldeinformationen einmal, führen Sie den ersten Upload aus, planen Sie ihn, bereinigen Sie die alten und stellen Sie ihn auf einem sauberen VPS wieder her, damit Sie wissen, dass der Plan funktioniert.

In diesem Ratgeber
  1. Warum der Same-Disk-Dump kein Backup ist
  2. Was Cipi tatsächlich hochlädt
  3. Was Sie brauchen
  4. Erstellen Sie den Bucket
  5. Einmalig Cipi konfigurieren
  6. Erstes Backup und Überprüfung
  7. Cron, Retention und Beschneiden
  8. Wiederherstellungsübung
  9. Backup vor jeder Veröffentlichung
  10. Fehler, die Backups unbrauchbar machen
  11. FAQ

Warum der Same-Disk-Dump kein Backup ist

Anbieter-Snapshots, a .sql.gz in /var/log, ein Tarball daneben storage/ – sie alle sterben mit der Maschine. Festplatte voll, Ransomware, ein dicker Finger rm -rf, ein regionaler Ausfall, ein gestohlener VPS: Die Kopie, die Sie brauchen, ist die, die bereits woanders war.

Die Regel, die immer noch gilt, ist 3-2-1: drei Kopien, zwei Medien, eine extern. Cipi deckt den letzten Hop ab. cipi db backup ermöglicht Ihnen ein schnelles lokales Rollback; cipi backup run versendet die Datenbank und die shared/ Ordner zu Amazon S3 oder einem beliebigen S3-kompatiblen Bucket. Das ist die Kopie, die Sie wiederherstellen, wenn die VPS weg sind.

Ein Backup, das Sie nie wiederhergestellt haben, ist eine Hoffnung, kein Plan. Planen Sie 20 Minuten nach dem ersten erfolgreichen Upload ein und führen Sie den Drill-In durch Wiederherstellen. Wiederholen Sie es vierteljährlich.

Was Cipi tatsächlich hochlädt

Bei jedem Lauf wird ein zeitgestempeltes Präfix für den Bucket erstellt:

s3://your-bucket/cipi/myapp/2026-08-22_020015/

In diesem Ordner erhalten Sie zwei Archive:

Code ist nicht im Archiv. Live-Veröffentlichungen in Git; Wenn Sie den letzten guten Baum benötigen, klonen Sie das Repo. Was Sie nicht klonen können, sind die Datenbank und die Dateien, die Benutzer nach dem Go-Live hochgeladen haben – diese beiden Dateien sind der Wiederherstellungspunkt.

Seitdem v4.7.14 Das Staging erfolgt auf der Festplatte /var/tmp, nicht in einem RAM-gestützten /tmp. Große Apps sterben nicht mehr mittendrin, weil die tmpfs voll sind. Überschreiben mit tmpdir in backup.json oder die CIPI_BACKUP_TMPDIR Umgebungsvariable.

Was Sie brauchen

Erstellen Sie den Bucket

Wählen Sie einen Anbieter aus und erstellen Sie einen privaten Bucket in einer Region nicht das gleiche Rechenzentrum wie der VPS und prägt ein Schlüsselpaar, das nur für diesen Bucket gilt. Aktivieren Sie die serverseitige Verschlüsselung, sofern der Anbieter diese anbietet. Die Versionierung ist eine optionale, aber kostengünstige Versicherung gegen versehentliches Überschreiben.

Mindest-IAM-Aktionen für diesen Bucket: s3:PutObject, s3:GetObject, s3:ListBucket, s3:DeleteObject. Letzteres ist nur erforderlich, wenn Sie möchten cipi backup prune um alte Präfixe zu bereinigen.

AnbieterEndpunkt-URL
AWS S3leer lassen
Hetzner-Objektspeicherhttps://<datacenter>.your-objectstorage.com
DigitalOcean Spaceshttps://<region>.digitaloceanspaces.com
Backblaze B2https://s3.<region>.backblazeb2.com
MinIOhttps://your-minio-host
Johnny (self-hosted S3)Ihre öffentliche Johnny-URL

Jeder S3-kompatible Shop funktioniert. Wenn Sie die Offsite-Kopie auf einem zweiten VPS in Ihrem Besitz haben möchten – nicht auf einer anderen SaaS-Rechnung – Johnny ist die open-source-Option, die bereits im erwähnt wurde self-hosted Entwicklerstapel.

Einmalig Cipi konfigurieren

Melden Sie sich per SSH als Admin-Benutzer an, werden Sie Root und führen Sie den Assistenten aus. Es schreibt/etc/cipi/backup.conf und Sie sollten es nicht erneut berühren müssen, es sei denn, der Schlüssel oder der Eimer ändert sich.

# as root on the VPS $ cipi backup configure # → AWS Access Key ID # → AWS Secret Access Key # → Bucket name # → Region # → Endpoint URL (empty for AWS; required for everyone else)

Behalten /etc/cipi/backup.conf Modus 600 und im Besitz von root. Diese Schlüssel öffnen jedes Backup, das Sie jemals erstellen werden. Wenn ein Schlüssel undicht ist, drehen Sie ihn beim Anbieter um und führen Sie ihn aus cipi backup configure noch einmal – alte Gegenstände bleiben im Eimer; Nur neue Uploads verwenden den neuen Schlüssel.

cipi db backup Funktioniert ohne Konfiguration. cipi backup run nicht. Wenn der Befehl S3 mit einem Anmeldeinformationsfehler fehlschlägt, haben Sie diesen Schritt übersprungen.

Erstes Backup und Überprüfung

Geben Sie nichts in cron, bis ein manueller Lauf im Eimer gelandet ist. Beginnen Sie mit einer einzigen App:

$ cipi backup run myapp # → s3://your-bucket/cipi/myapp/2026-08-22_143015/db.sql.gz # → s3://your-bucket/cipi/myapp/2026-08-22_143015/shared.tar.gz $ cipi backup list myapp $ cipi backup run # no app name = every app on the server

Bestätigen Sie dann über die Anbieterkonsole – oder mit AWS CLI, das bei Bestehen auch mit kompatiblen Endpunkten kommuniziert --endpoint-url:

$ aws s3 ls s3://your-bucket/cipi/myapp/ $ aws s3 ls s3://your-bucket/cipi/myapp/2026-08-22_143015/

Sie sollten beide Objekte sehen, mit Größen, die einem komprimierten Dump plus dem entsprechen shared/ Baum. Ein 200-Byte-Objekt bedeutet normalerweise einen leeren Dump oder einen fehlgeschlagenen Upload – beheben Sie das, bevor Sie etwas planen.

Cron, Retention und Beschneiden

Täglich um 02:00 Uhr ist die langweilige Standardeinstellung. Beschneiden um 03:00 Uhr, damit der gestrige Lauf nie durch ein Rennen gelöscht wird. Vier Wochen Verlauf reichen für die meisten Laravel-Apps; Senken Sie den Wert auf zwei, wenn die Budgetrechnung schmerzt, und erhöhen Sie ihn auf acht, wenn Sie einen langsamen Datenverlust beheben müssen.

# crontab -e as root 0 2 * * * /usr/local/bin/cipi backup run myapp >> /var/log/cipi/backup.log 2>&1 0 3 * * * /usr/local/bin/cipi backup prune myapp --weeks=4 >> /var/log/cipi/backup-prune.log 2>&1

Um jede App auf der Box zu sichern, löschen Sie den App-Namen aus beiden Befehlen. cipi backup prune liest sich genauso /etc/cipi/backup.conf und funktioniert mit jedem kompatiblen Anbieter.

$ cipi backup prune myapp --weeks=4 $ cipi backup prune myapp --weeks=2

Beobachten Sie /var/log/cipi/backup.log für eine Woche. Eine stille cron, die am ersten Tag fehlschlug, ist der Grund dafür, dass Menschen am Morgen nach einem Festplattenausfall feststellen, dass sie keine Backups haben.

Wiederherstellungsübung

Tun Sie dies mit einer Staging-App oder mit einem freien VPS, nicht beim ersten Mal im Live-Verkehr. Der glückliche Weg von einem S3-Präfix zurück zu einer laufenden App:

$ cipi backup list myapp $ aws s3 cp s3://your-bucket/cipi/myapp/2026-08-22_143015/db.sql.gz /tmp/db.sql.gz $ cipi db restore myapp /tmp/db.sql.gz $ aws s3 cp s3://your-bucket/cipi/myapp/2026-08-22_143015/shared.tar.gz /tmp/shared.tar.gz $ tar -xzf /tmp/shared.tar.gz -C /home/myapp/

Wenn das VPS selbst weg ist, ist die Reihenfolge: Cipi auf einer neuen Ubuntu-Box installieren, cipi app create mit der gleichen Git-Remote, dann die beiden oben genannten Wiederherstellungen cipi ssl install und ein DNS-Schnitt. Die Infrastrukturdokumente Listen Sie dieselben Befehle auf. Diese Übung ist der Teil, den die meisten Leute überspringen.

Bei einem Rollback auf demselben Server – fehlerhafte Migration, fehlerhafte Bereitstellung – ist der lokale Dump schneller:

$ ls -lh /var/log/cipi/backups/myapp_*.sql.gz $ cipi db restore myapp /var/log/cipi/backups/myapp_20260822_143012.sql.gz $ cipi deploy myapp --rollback

Lokale Mülldeponien /var/log/cipi/backups/ werden niemals automatisch gelöscht. Bei einem vollen Einsatzplan füllen sie die Festplatte. Behalten Sie die letzten fünf und lassen Sie den Rest fallen: ls -t /var/log/cipi/backups/myapp_*.sql.gz | tail -n +6 | xargs rm -f.

Backup vor jeder Veröffentlichung

Webhook Die automatische Bereitstellung kann nicht für ein Backup angehalten werden – der Push wird ausgelöst cipi deploy sofort. Platzieren Sie für die Produktion eine Backup-Stufe im CI, damit ein fehlgeschlagener Dump die Veröffentlichung blockiert. Die vollständigen GitHub Aktionen und GitLab Beispiele finden Sie hier Sichere Bereitstellung – Sicherung vor der Veröffentlichung. Die beiden Befehle, die Sie in dieser Phase benötigen:

$ cipi db backup myapp # fast local rollback $ cipi backup run myapp # off-site copy of DB + shared/

Zusammen erhalten Sie eine Wiederherstellung in derselben Box, die Sekunden dauert, und ein S3-Präfix, das Sie immer noch öffnen können, wenn die Box nicht mehr vorhanden ist. Wenn einer der Befehle fehlschlägt, führen Sie die Bereitstellung nicht durch.

Fehler, die Backups unbrauchbar machen

Führen Sie es auf einem Cipi VPS aus

Cipi ist die kostenlose, open-source Laravel Bereitstellung CLI, die in diesem Handbuch verwendet wird. Ein Befehl verwandelt einen frischen Ubuntu VPS in einen gehärteten Produktionsserver – und cipi backup configure ist der Schritt, der den Server überlebensfähig macht.

wget -O - https://cipi.sh/setup.sh | bash
Starten Sie kostenlos durch Referenz CLI sichern Stern auf GitHub

Häufig gestellte Fragen

Funktioniert Cipi nur mit Amazon S3?

Nein. cipi backup configure akzeptiert jeden S3-kompatiblen Endpunkt: Hetzner Object Storage, DigitalOcean Spaces, Backblaze B2, MinIO oder einen self-hosted Store wie z Johnny. Lassen Sie den Endpunkt für AWS leer. Füllen Sie es für jeden anderen Anbieter aus.

Was ist der Unterschied zwischen cipi db backup und cipi backup run?

cipi db backup schreibt einen komprimierten SQL-Dump auf das gleiche VPS darunter /var/log/cipi/backups/. Es ist immer verfügbar und erfordert keine Konfiguration. cipi backup run Gibt die Datenbank und die App aus shared/ Ordner und lädt dann beide Archive in Ihren S3-Bucket hoch. Verwenden Sie den lokalen Dump für ein schnelles Rollback; Verwenden Sie die S3-Kopie für eine echte Offsite-Wiederherstellung.

Wie oft sollte ich ein Laravel VPS sichern?

Täglich ist der sinnvolle Standardwert für die Produktion. Hinzufügen cipi backup run Zu einer ruhigen Stunde bis zum Wurzel-Crontab schneiden, dann älter als vier Wochen beschneiden. Wenn sich die Datenbank ständig ändert, führen Sie sie zweimal täglich aus. Führen Sie vor einer riskanten Migration oder einer Produktionsbereitstellung immer ein Backup durch.

Kann ich ein Cipi S3 Backup auf einem neuen VPS wiederherstellen?

Ja – das ist der Sinn einer Offsite-Kopie. Installieren Sie Cipi auf einem neuen Ubuntu VPS, erstellen Sie die App neu und laden Sie sie herunter db.sql.gz und shared.tar.gz Stellen Sie die Datenbank aus dem Bucket wieder her mit cipi db restore, und extrahieren shared/ hinein /home/<app>/.

Wo speichert Cipi S3-Zugangsdaten?

cipi backup configure schreibt ihnen /etc/cipi/backup.conf. Behalten Sie diese Datei nur als Root-Datei. Die gleichen Anmeldeinformationen werden von verwendet cipi backup run, list und prune. Das Staging großer Archive erfolgt standardmäßig auf /var/tmp also ein kleines RAM-Backup /tmp bricht den Job nicht ab.

Lesen Sie weiter

Setze Laravel auf Ubuntu ein Laravel Sicherheitscheckliste CI/CD für Laravel Dokumente: cipi Backup Sichere Bereitstellung mit Backup