Wir befinden uns an einem Punkt in unserer Entwicklung, in der wir jeden Tag unvorstellbar große Mengen an Daten absichtlich oder unabsichtlich produzieren. Selbst dieser Mausklick oder der gerade geführte Telefonanruf produzierte einen Datensatz.

Diese Datenmengen nehmen exorbitant zu — ein Problem für jeden Systemadministrator (Stichwort Redundanz, Backup, Aktualität, Performance). Deshalb ist es an der Zeit, eine Speicherplatz/Nutzen Analyse zu machen. Welche Daten werden denn überhaupt benötigt, welche können aus anderen Daten generiert werden (Redundanz) und welche sind komplett überflüssig?

In Firmen in denen Software produziert wird, entstehen verhältnismäßig viele Daten. Jede Version, jeder Zwischenstand und jede Codeänderung wird festgehalten. Um hier den Überblick zu behalten und das Datenvolumen kontrolliert wachsen zu lassen, hier ein paar Tipps.

-vvv

Für das Debugging sind Log-Ausgaben extrem wichtig. Prinzipiell hat man bei der Entwicklung und bei der Fehlersuche nie genug Daten. Einige Programme haben deshalb entsprechende Schalter (meist -v, –verbose, –debug oder –more), um jedes interne Detail des Prozesses ausgeben zu lassen. Ist der Fehler gefunden oder der Programmcode auf dem Live-Server im Einsatz, machen solche Optionen keinen Sinn mehr. Man sollte also nicht vergessen, die Log-Ausgabe wieder dementsprechend anzupassen.

/tmp

Temporäre Dateien, der Browser-Cache oder der Inhalt des Papierkorbs — alles kurzzeitig sinnvolle Daten, doch schnell sind sie unwichtig und werden nie wieder benötigt. Solche Daten entstehen auch gerne auf USB-Sticks oder im Postausgang. Gerade bei größeren Dateien ist dies ärgerlich, da sie unnötig Platz auf der Festplatte und demzufolge auch im Backup belegen. Um diesem schleichenden Datenmüll entgegenzuwirken, gibt es effektiv nur eine Lösung: Automatisiert löschen. Der Papierkorb oder das /tmp-Verzeichnis beim Herunterfahren löschen, das temporäre Austausch-Laufwerk jeden Freitag Abend säubern und den USB-Stick bei jeder Benutzung vorher formatieren. Das spart nicht nur Platz, sondern sorgt auch dafür, das sensible Daten nicht unbeabsichtigt die Firma verlassen.

Das Backup vom Backup

Jedem Admin sollte klar sein, an welchen Stellen ein Backup gebraucht wird und was am Ende im Backup landet. Redundanz ist wichtig, allerdings gibt es einige Konstellationen, bei denen es nicht viel Sinn ergibt, ein weiteres Backup anzulegen. Wird beispielsweise ein Backup eines Verzeichnisses auf dem selben Server angelegt, welcher wiederum von einem anderen Backup-Mechanismus komplett gesichert wird, belegt es nur unnötig Platz. Solche Redundanzen sind manchmal sogar gewollt, wenn das Wiederherstellen eines Backups zu lange dauert, zu aufwendig ist oder gar noch nie versucht wurde. In diesen Fällen sollte man sich dann grundlegendere Gedanken über die eingesetzte Backup-Strategie machen.

…_v2.new.zip

Ist kein vernünftiges Versionierungssystem vorhanden, wird häufig zu Behelfslösungen gegriffen. Dateien werden mit Zahlen bestückt oder erhalten nichtssagende Bezeichnungen wie „neu“, „back“, „old“ oder „tmp“. Spätestens nach 2 Tagen hat auch der Ersteller vergessen, welcher Stand sich hinter dem Suffix verbirgt. Wenn es keine andere Möglichkeit gibt, muss man zu diesem Mittel greifen. Man sollte dabei allerdings das Suffix so wählen, dass klar ist, was damit gemeint ist. Ein Beispiel:

arbeitsmeeting_2012-07-12
├── protokoll_arbeitsmeeting_am.docx
├── protokoll_arbeitsmeeting_am_mq.docx
├── protokoll_arbeitsmeeting_am_mq_fl.docx
└── protokoll_arbeitsmeeting_am_mq_fl_HZ.docx

Hier ist schnell klar, was für eine Entwicklung dieses Dokument erfahren hat. Es wurde von einigen Personen (repräsentiert durch das Kürzel) nacheinander bearbeitet und ergänzt. Die letzte Person erklärte das Dokument als final (Großgeschrieben). Somit können ganz unbedenklich die anderen drei Dateien von jedem gelöscht werden, ohne bedenken zu haben, etwas essenzielles zu löschen. Dies ist nur ein Beispiel für eine Konvention/Regel. Natürlich muss jedem, der damit arbeitet, klar sein, was es für Regeln gibt und wie deren Semantik ist. Hält sich jeder daran, spart es eine Menge Dateileichen ein.

JavaDoc, Buildfiles und *.o

Daten, die aus anderen Daten generiert werden, müssen nicht zwangsläufig in einem Backup gesichert werden. Die API Dokumentation zu JavaCode lässt sich jederzeit aus dem Code neu generieren. Ebenso Object-Files, generierte Testdatenbanken oder Binaries, die nicht für den Kunden bestimmt sind. Vermeiden lässt sich dies je nach System über Filter bzw. Ignore-Listen. Für git gibt es die Datei .gitignore, unter Subversion gibt es das svn:ignore Property.

.DS_STORE und .thumbs

Es gibt allerdings auch Daten, die unabsichtlich angelegt werden. Beispielsweise die .DS_STORE Dateien für die erweiterten Verzeichnisattribute oder die .thumbs Dateien der Windows Vorschaufunktion. Diese Dateien sind in den allermeisten Fällen schlicht unnötig und lassen sich Betriebsystemseitig ausstellen. Alles was sich so nicht ausstellen lässt, kann automatisiert durch ein Script entfernt werden.

[gist id=3099541]

Ein Frühwarnsystem

Trotz aller Vorkehrungen lässt es sich aber nicht vermeiden, dass die Datenmenge kontinuierlich wächst. Um aber darauf frühzeitig reagieren zu können, haben wir ein Frühwarnsystem entwickelt. Unverhältnismäßige Anstiege im Datenvolumen pro Verzeichnis/Projekt werden so erkannt und das Datenvolumen bleibt handelbar.

(Das Script ist in Ruby geschrieben und kann frei verwendet werden.)

[gist id=3099629]
0 Kommentare

Dein Kommentar

An Diskussion beteiligen?
Hinterlasse uns Deinen Kommentar!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.