Vergangene Nacht ist bei Gitlab.com der Worst Case eingetreten: durch den Fehler eines Systemadministrators wurde die Produktivinstanz der Datenbank versehentlich gelöscht. Die anschließende Wiederherstellung eines aktuellen Backups schlug auf diversen Wegen fehl, sodass ein 6 Stunden älteres Backup eingespielt werden musste.
Solche Szenarien gehören sicherlich zu den GAU-Szenarien eines jeden Unternehmens. Auch wenn sich in diesem Fall die Backup-Strategie von Gitlab.com in der Praxis nicht bewährt hat (da wird nach diesem Vorfall ganz bestimmt nochmals nachgearbeitet werden), so fand die Außenkommunikation in meinen Augen vorbildlich statt. Neben Status-Updates über Google Docs sowie den Blog gab es zudem einen Live-Stream, der einen interessanten Einblick während der Arbeiten gewährte. Über den damit verbundenen Chat wuden auch aufkommende Fragen live beantwortet.
Auch wenn der Ausfall unter dem Strich eine ärgerliche Angelegenheit bleibt, bieten solche Geschehnisse immer eine Möglichkeit, das ganze mit einer offenen Außenkommunikation etwas positiver abzufedern.
PS: Der „schuldige“ Systemadministrator wurde übrigens nicht gefeuert. Im Gegenteil, durch diesen Fehler ist er laut Gitlab.com in Zukunft deutlich gegenüber dieser Problematik sensibilisiert – diese Sicht finde ich klasse! 🙂
Vor einer Woche staunte ich nicht schlecht als ich tagsüber den Server routinemäßig kontrollierte. Der Serverload lag bei 1.0 (das entspricht ungefähr der Auslastung eines Kerns, wobei eigentlich noch der I/O Wert zu beachten ist). Ein kurzer Blick in die Prozessliste förderte bzip2 als „Übeltäter“ zu Tage. Da konnte nur der Backupprozess in Frage kommen, doch eigentlich sollte dieser zu jener Tageszeit schon längst beendet worden sein. Wieso lief bzip2 also nicht rund? Eine schnelle Ursache konnte ich nicht finden und habe das ganze erst einmal weiter beobachtet. Doch auch in den Folgenächten besserte sich die Situation nicht. Es ging also ins Detail. Nebenbei untersuchte ich gleichzeitig Möglichkeiten, um den Backupprozess zu beschleunigen. Die weitere Ursachenforschung brachte letztendlich das wahre „Problem“ zum Vorschein: die Größe der zu sicherenden Daten belief sich auf über 250 GB – da konnte etwas nicht stimmen! Und siehe da, das Problem war ein hausgemachtes. Ich hatte bei der letzten Migration auf die neusten Softwareversionen der LAMP-Umgebung die MySQL Replikationslogs in ein zu sicherendes Verzeichnis mitverschoben und diese hatten nunmal einen Umfang von mehr 200 GB (was ohnehin unnütz ist, aber so leert sich nun auch ein weiterer Punkt auf der ToDo Liste..). Nach der Entfernung dieser Dateien gestaltete sich der Backupprozess auch wieder ähnlich flott wie zuvor. Die parallelen Optimierungsarbeiten am Backupscript hatten auch ihre gute Seite: bzip2 wird fortan durch pbzip2 ersetzt, das nun alle Kerne nutzt.
Externe Festplatten sind sehr nützlich, vor allem wenn man das Thema Backup angeht. Nachdem ich die letzten Tage wieder etwas im Kaufrausch war (back to the roots sozusagen, irgendwann stellt man anderweitige Aktivitäten wieder etwas hinten an, die dann auf Dauer doch nicht so vielversprechend erscheinen..), habe ich mir gestern spontan die oben genannte Platte geordert. Dank Amazon Prime und DHL Express ist sie heute bereits eingetroffen und hängt nun schon an der Fritz!Box. Zwar soll die NAS Performance der Box nicht sehr berauschend sein, aber das werde ich dann in den kommenden Wochen testen. Bis dahin müssen die ersten Sicherungen noch warten, zuerst steht eine Datenmigration an. Sämtliche Dokumente sind auf drei Computern verstreut, insofern wird eine vorherige Synchronisation unumgänglich sein. Diese Arbeiten müssen sich nächste Woche aber erst einmal hinter dem Samsung Galaxy S2 einreihen – und natürlich hinter den anstehenden Serverarbeiten am darauffolgenden Wochenende. Der erste Schritt ist mit dem Kauf aber getan 🙂
Je später die Abendstunde, desto kreativer die Titel. Nein, ich habe noch nicht zu tief ins Weinglas geschaut (neben mir steht genauer gesagt eine Coladose! ;-)), sondern bin noch fleißig am Server zugange. Mittlerweile läuft das eingerichtete und angepasste Backupscript erfreulich gut. Auch wenn ein Strato Serverbuch aus vergangenen Jahren nicht wirklich viel neues enthielt, so war das dortige Backupscript als Ideengeber eine gute Basis. Vervollständigt um die E-Mail Benachrichtigung und einige kleine Anpassungen läuft es nun seit zwei Wochen täglich und legt die Backups auf den FTP-Server ab. Nur eine Sache ist mir beim heutigen Backup eben noch aufgefallen: bzip2 ist auf einen einzigen Kern ausgerichtet und die ganze Komprimierungsphase läuft so nur auf einem Kern ab. Das ist allerdings nicht weiter wild, das gesamte Backup (Sichern – Komprimieren – auf den FTP-Server laden) benötigt ohnehin nur eine gute halbe Stunde. 7-Zip scheint da Quad Core freundlicher zu sein, vielleicht ein Thema für die Zeit danach.
Demnächst geht’s nun erstmal ans Thema Backup der Computer zuhause. Hat hier jemand schon Strategien? Demnächst muss wohl eine externe 2 TB Festplatte her.
Wird ein Heimserver bald Realität? Zwar landete dieser immer mal wieder auf der ToDo-Liste, mangels passender Einsatzmöglichkeiten und vor allem aufgrund des dedizierten Servers verschwand er aber stets nach kurzen Überlegungen wieder. Das könnte sich nun ändern, denn während der Suche nach einer neuen Backuplösung – möglicherweise gerade in Form eines Heimservers – kam dieser Punkt wieder zum Vorschein. Und gerade hier entfaltet sich auch das Potential eines Heimservers. Denn zusätzlich zu den Systemsicherungen der lokalen Systeme könnte dieser auch dazu genutzt werden, Backups auf dem dedizierten Server regelmäßig selbständig herunterzuladen. Ergänzungen wie der Einsatz als Fileserver kämen möglicherweise auch in Betracht, aber das ließe sich auch noch in der Planungsphase oder im späteren Verlauf festlegen. Auf jeden Fall sind die Berechtigungsgründe eines Heimservers langsam gegeben. Ein spannendes Thema, das sich mit etwas Planung im Betrieb auszahlen könnte. Angesichts dieser Gedankenansätze würde mich interessieren, ob hier vielleicht schon jemand Erfahrungen mit Heimservern gemacht hat und wie sich der Einsatz des Heimservers im Alltag widerspiegelt.
Mittlerweile scheint mein Handy durch die Fülle der Daten regelrecht absturzgefährdet zu sein, das zeigen des öfteren Abstürze. Schon vor einiger Zeit hatte ich aus diesem Grund vor, die gespeicherten SMS auf den Computer zu übertragen und dann den Handyspeicher zu leeren. Doch schien dieser Vorgang viel Zeit zu beanspruchen, jedenfalls gingen die kopierten Mitteilungen nach und nach nur zögerlich auf die Reise. Aus diesem Grund habe ich das ganze soweit hinausgezögert, das es nun wirklich notwendig erschien. Überraschenderweise ging die Sicherung diesmal sehr schnell – die Mitteilungen strömten nur so auf den Computer. Bei einer großen Stückzahl ist das kein leichtes unterfangen und wenn das Handy dann noch zusätzlich durch Abstürze auf sich aufmerksam macht, ist man mehr als froh, wenn’s dann endlich vorbei ist. Nun hoffe ich nur noch, dass mit der Leerung des Handyspeichers auch die Absturzprobleme behoben sind, das Nokia 6234 machte in Sachen Bugs schon von sich reden. Denn wenn man eins nicht gebrauchen kann, dann sind es gerade Probleme bei einem Alltagsgegenstand wie dem Handy.
T-Online, GMX & Co bieten heute neben ihren E-Mail Tarifen meist bereits enthaltene Medien Center an, die Speicherplatz für Urlaubsfotos oder persönliche Daten bieten und nach Wunsch auch die Bereitstellung an Gäste ermöglichen. Dabei lässt sich das ganze um einen weiteren Zweck vergrößeren: für Backups sind die dargebotenen Medien Center ebenfalls nützlich. Zwar nicht im großen Stil, das verhindern zum einen die Transfervolumenbeschränkungen und zum anderen stellt der Speicherplatz im Medien Center im Verhältnis zu den lokalen Daten meist nur einen Bruchteil dar, aber für kleinere Dinge ist es allemal ausreichend. Für Office-Dokumente, PDF Dateien oder neuerdings elektronische Rechnungen eignet sich der Platz geradezu prädestiniert. Meistens erfolgt der Zugriff auf die Medien Center via Browser, gerade beim Transfer vieler Dateien stellt sich das schnell als Hindernis heraus. Viele Anbieter stellen aber ebenfalls eine WebDAV Schnittstelle bereit, anhand deren sich das Medien Center bequem in den Explorer integrieren lässt und von dann an die gewohnten Dateioperationen auf Explorerebene ermöglicht.
Wer das nächste Mal also an ein Medien Center geraten sollte und auf den ersten Blick keinen Zweck darin sieht, dürfte vielleicht ein wenig inspirierter von dieser Möglichkeit sein.
3 Arbeitstage (ohne Zählung der Tage dazwischen) hat es gedauert, bis der neue Server nun inklusive Übertragung der Backups soweit wieder eingerichtet ist. Dabei verlief die Migration ausgesprochen reibungslos, so langsam wird das ganze zur Routine 🙂 Nun müssen die ganzen Backups zur Sicherheit nur noch zusätzlich auf meinen lokalen Computer übertragen werden, was angesichts einer Größe von etwa 16 GB aber kein Zuckerschlecken sein wird. Auch mit einem ADSL2+ 16 Mbit Anschluss dauert das bei einer solchen Größe noch gute 3 Stunden. Wohl dem, der an einem Sonntag genügend Zeit mitbringt 😀