Ich wechsele von VPS zu dedizierten Servern. Leider bieten die meisten dedizierten Server keine Server-Backups wie verwaltete VPS, und ich schätze die Gewissheit, ein Backup aller meiner Skripte/Dateien zu haben, falls etwas schief geht (was schon einmal passiert ist).
Die Frage ist also, ob es möglich ist, täglich „Snapshots“ bestimmter Verzeichnisse zu erstellen, die auf demselben Server, aber in unterschiedlichen Ordnern gespeichert werden.
Verständlicherweise schützen diese Backups nicht vor externen Katastrophen. Mir geht es eher um Schutz vor Schäden durch bösartige Skripte/Hacking usw.
Antwort1
Sie suchen wahrscheinlich nach etwas wie Webmin:http://webmin.com/
Es ist ein obligatorischer Bestandteil meiner CentOS-Server-Setups. Es ist wirklich einfach zu installieren und macht die Serververwaltung zum Kinderspiel, insbesondere das Sichern von Daten. Schauen Sie sich die Dokumentation hier an:http://doxfer.webmin.com/Webmin/FilesystemBackup
Antwort2
Ist es möglich, täglich „Schnappschüsse“ bestimmter Verzeichnisse zu erstellen, die auf demselben Server, aber in unterschiedlichen Ordnern gespeichert werden? ... zum Schutz vor Schäden durch bösartige Skripte/Hacking usw.
Ja, jeder derviele Softwaretools zur Revisionskontrolledas wird genau das tun.
Ich verwende Mercurial („hg“), oft mit dem hübschen GUI-Frontend TortoiseHg.
Auf vielen meiner Server gibt es einen Ordner(*), vielleicht „/var/www/“, der alles enthält, was ich sichern möchte – Einstellungsdateien, Vorlagen, benutzerdefinierte serverseitige CGI-Bin-Skripte, benutzerdefinierte browserseitige .js-Skripte, .html-Inhalte usw. (Alles andere auf dem Rechner ist Standardkram für Betriebssystem und Anwendungen. Wenn dieser Kram beschädigt wird, würde ich ihn wahrscheinlich löschen und die neueste Version davon installieren, anstatt zu versuchen, zu der alten, veralteten Version zurückzukehren, die ich verwendet habe).
Wenn ich die Dinge zum ersten Mal einrichte, gehe ich in diesen Ordner und führe die einmalige Einrichtung durch
hg init
hg add
hg commit -u dc -m "initial setup"
Die Zeile „init“ erstellt einen Ordner „.hg/“, in dem eines Tages komprimierte Snapshots gespeichert werden. (daher der Name eines beliebten Mercurial-Tutorials,http://hginit.com/). Die Zeilen „add“ und „commit“ scannen standardmäßig jede Datei in diesem Ordner, egal wie tief sie in Unterordnern verschachtelt ist, und legen eine (komprimierte) Kopie in diesen Ordner „.hg/“ ab.
Wenn ich eine Beschädigung oder andere Änderung an den Arbeitsdateien vermute (und davon ausgehe, dass der Ordner „.hg“, der alle Snapshots enthält, unbeschädigt ist), tippe ich
hg status
Das sagt mir genau, welche Dateien sich geändert haben, egal wie tief sie in einem Unterordner verschachtelt sind, dann tippe ich
hg diff
das mir genau sagt, was sich in jeder Datei geändert hat.
Wenn mir nicht gefällt, was ich sehe - es sind böswillige Änderungen, oder häufiger, es sind meine eigenen dummen Änderungen, die ich jetzt bereue -, tippe ich
hg revert --all
um alle Änderungen auf das letzte Commit zurückzusetzen.
Wenn ichTungefällt mir, was ich sehe -- ich habe etwas optimiert, was es tatsächlich besser macht -- ich tippe so etwas wie
hg add
hg commit -u dc -m "tweaked .htaccess so we now have Clean URLs."
mit einem Kommentar, der hoffentlich beschreibt, warum ich diese Änderungen vorgenommen habe. (Es gibt Möglichkeiten, nurmancheder Dateien und nurmancheder Dateien und sogar Möglichkeiten, nurmancheder vielen Änderungen, die an einer einzelnen Datei vorgenommen wurden – Einzelheiten finden Sie in der Dokumentation).
Vielleicht möchten Sie lieber einen Cron-Job, der täglich etwas tut wie
hg add
hg commit -u mr_backup -m "cron automated snapshot of the server."
Ein komprimierter Snapshot jeder Version, die jemals festgeschrieben wurde, bleibt im Ordner „.hg/“. Es gibt einen „hg update“-Befehl, um zu jeder festgeschriebenen Version zurückzukehren. Es gibt einen „hg diff -r 1:2“-Befehl, um genau zu sehen, was sich zwischen dem ersten und dem zweiten Festschreiben geändert hat.
komplexere Situationen
(*) Oft gibt es nur einen Ordner, den ich sichern möchte ( "/var/www/" ). Manchmal ist die Situation jedoch komplexer - die Dateien, die ich sichern möchte, sind in einer Reihe verschiedener Ordner verstreut, und der einzige gemeinsame Ordner ist der Stammordner "/", und ich möchte das ".hg/"-Repository nicht im Stammordner "/.hg/" ablegen.
Es gibt wahrscheinlich eine bessere Möglichkeit, damit umzugehen, aber was ich gerade mache, ist:
- Ich erstelle einen speziellen Benutzer namens „MrBackup“, der nur Leseberechtigung für alle Dateien hat, die ich sichern möchte.
- Ich habe alles so eingerichtet, dass jeder Ordner, den ich sichern möchte, als Unterordner von /home/mr_backup angezeigt wird. Derzeit habe ich eine zufällige Mischung aus:
- Einige Dateien befinden sich tatsächlich im Home-Ordner von MrBackup und zu dem anderen Ort, an dem sie „sein müssen“, gibt es einen Softlink.
- Einige Dateien verfügen über einen Hardlink zu beiden Orten – dem Ort, an dem sie „sein müssen“ und auch irgendwo im Home-Ordner von MrBackup.
- Ein Cron-Skript kopiert in regelmäßigen Abständen einige Dateien vom „Live“-Speicherort in einen Sicherungsordner im Home-Ordner von MrBackup, speichert möglicherweise eine SQL-Datenbank von einem anderen Server in einer Dump-Datei im Home-Ordner von MrBackup und erstellt außerdem eine Sicherungskopie des Cron-Skripts selbst („crontab -l > /home/mr_backup/backup/crontab.txt“).
- Oft möchte ich fast alles in einem Ordner P sichern, außer einem Unterordner „cache/“, den ich nicht sichern muss, da er bei Bedarf automatisch neu erstellt wird. Ich verwende „.hgignore“, um den Cache-Unterordner auszuschließen.
- Dann verwende ich Mercurial, wie oben.
- Wenn die vom Cron-Skript generierten Dateien nach einer Rückgängigmachung nicht richtig aussehen, muss ich einige zusätzliche Schritte unternehmen, um die „gute Version“ irgendwie wieder an den „Live“-Speicherort zu übertragen.
ps: Auf einer Maschine in einer anderen Stadt als meinem Server starte ich gelegentlich die TortoiseHg-Workbench und klicke auf den kleinen Knopf, der im Hintergrund läuft
hg pull
(und fragt mich nach dem Passwort von Mr Backup), um ein externes Backup von allem zu erhalten, was im Repository gespeichert wurde.
Anstatt Änderungen live auf dem Produktionsserver vorzunehmen, ist es normalerweise besser, die Änderungen auf einem anderen Computer vorzunehmen, sie dann zu bestätigen und
hg push
sie auf den Produktionsserver.
Der Ordner ".hg/" wächst ständig - sehr langsam, da er nur Dateien speichert, dieändernvon einem Commit zum nächsten, und selbst diese relativ kleinen Änderungssätze werden komprimiert, bevor sie gespeichert werden.
Es gibt wahrscheinlich einen besseren Weg, mit diesem langsamen Wachstum umzugehen, aber ich gehe derzeit folgendermaßen vor:
Nachdem ich die aktuelle Version per „hg commit“ und dann per „hg pull“ auf meine externe Backup-Maschine geladen habe, lösche ich einmal im Jahr den Ordner „.hg/“ des Servers und erstelle mit „hg init“ einen neuen, leeren Ordner „.hg/“, und dann übertrage ich die aktuelle Version. (Die letzte Version des externen Backup-Repositorys von 2014sollenmit der ersten Version des Offsite-Backup-Repositorys von 2015 identisch sein).