Sollte ich für vollständige Server-Backups eine separate Partition erstellen?

Sollte ich für vollständige Server-Backups eine separate Partition erstellen?

Bevor ich mit der Frage anfange, möchte ich nur festhalten, dass ich kein Systemadministrator bin, sondern ein Laie, der Hilfe sucht.

Ich verwende Linux 3.10.0-514.26.2.el7.x86_64 und den externen Backup-Dienst von Amazon Web Services. Damit das funktioniert, benötige ich ein Backup-Verzeichnis auf meinem Server, in das alle Dateien komprimiert, kopiert und vom externen Backup-Dienst abgerufen werden.

Die Frage ist: Soll ich in diesem Verzeichnis eine separate Partition mounten? Backups können viel Festplattenspeicherplatz beanspruchen, und eine separate Partition für diesen Zweck sollte theoretisch meine täglichen Servervorgänge und Websites vor Problemen mit wenig freiem Festplattenspeicher schützen.

Aber ist das der richtige Ansatz? Gibt es einen besseren?

Antwort1

Ich möchte einer anderen Antwort mit allem Respekt widersprechen und sagen, dass eine ordnungsgemäße Partitionierung in vielerlei Hinsicht für die Wartung von Linux-Servern unerlässlich ist (zu Windows kann ich nicht viel sagen, da dies nicht meiner Erfahrung entspricht).

Ich verwende für Backups immer eine separate Partition und das war unglaublich hilfreich, nicht nur für die richtige Planung des Speicherplatzes, sondern auch für den Wiederherstellungsprozess. Lassen Sie mich das unten skizzieren (verzeihen Sie die schlechte Formatierung, da ich dies von meinem Telefon aus tippe):

  1. Eine separate Partition ermöglicht eine Kapazitätsisolierung, sodass, wenn etwas den gesamten freien Speicherplatz auf dieser Partition aufbraucht, dies keine Auswirkungen auf den Rest des Systems hat. Denken Sie beispielsweise an /var/log. Ich habe Server gesehen, auf denen Benutzer unbeabsichtigt Logrotate unterbrochen haben und die Protokolle 100 % des Root-Speichers verbraucht haben (oder das könnte beispielsweise bei einem plötzlichen Anstieg des Datenverkehrs passieren).

  2. Eine separate Partition auf einer separaten Festplatte im Falle von AWS ermöglicht es Ihnen, sie in eine andere Instanz einzubinden und Ihre Daten dort wiederherzustellen (z. B. für forensische Untersuchungen).

  3. (Nicht nur im Zusammenhang mit der Datensicherung) Bei einer separaten Partition können Sie beim Mounten die Eigenschaft „noexec“ festlegen, um mögliche unbefugte Zugriffe zu minimieren (das sollte eigentlich für die meisten Partitionen im System gemacht werden, außer für diejenigen, auf denen sich Ihre ausführbaren Dateien befinden).

Da Sie nun erwähnen, dass es sich um ein AWS-System handelt, würde ich empfehlen, statt einer separaten EBS-Festplatte auf dem Server die S3fs-Erweiterung zu verwenden und einen S3-Bucket als Partition für Backups zu mounten. Der Vorteil davon ist die lange Haltbarkeit der Daten auf S3.

Beachten Sie 2 Punkte: Sie MÜSSEN immer die erfolgreiche Ausführung von Backups überwachen und Sie MÜSSEN regelmäßig die Wiederherstellbarkeit von Daten testen (lesen Sie, wasist zum Beispiel mit Gitlab passiert)

Wenn Sie sich außerdem für eine weitere EBS-Festplatte entscheiden, vermeiden Sie um jeden Preis die Verwendung von LVM, da 1. die Fragmentierung der LVM-Partition auf mehrere Festplatten leicht zu Datenverlust führen kann (leider ist LVM noch nicht so gut, wie es sich die Entwickler wünschen) und 2. Sie können jetzt EBS-Festplatten auf AWS vergrößern und so mehr Speicherplatz ohne LVM-Fragmentierung hinzufügen.

Antwort2

Nein. In Ihrem Fall machen Partitionen das Leben auf lange Sicht nur schwerer. Sie multiplizieren nur die Punkte möglicher zukünftiger * Fehler.

Für Probleme mit geringem Speicherplatz gibt es zwei Lösungsmöglichkeiten:

  1. Überwachung (sofortige Reaktion).
  2. Kapazitätsplanung (langfristig).

Wenn Sie diese implementiert haben undDannSie würden feststellen, dass einigeSehr geheimnisvollWenn die Aktivität die Größe Ihrer Backups plötzlich in die Höhe treiben kann, hätten Sie ein (wackeliges) Argument für die Einführung einer Partitionierung.

[*] Ihre erste Pflicht als Systemadministrator (was Sie tatsächlich sind) besteht darin, viel pessimistischer zu sein als Ihre Benutzer.

verwandte Informationen