13 – 17 June offered tips galore, from implementing code standards to using Time Machine with network drives and DRBD with Redhat.
To begin, Julian updated his tip for Apple Time Machine with network sharing. Previously, he explained how to set up Time Machine to back up to shared network drives with the help of Snow Leopard. Now in 8 steps, he offered a new method starting from setting a hidden configuration parameter, host name and MAC address, to creating a local sparse bundle on the network drive and adjusting Time Machine’s settings.
From using shared storage to avoiding them, Philipp shared his recipe for using DRDB to mirror hard disks over multiple servers on Redhat. He first offered a simple method with CentOS Extra Repository that works for versions up to RHEL 5.6. For version 6 and onwards, Philipp showed how to prepare and compile a DRBD package to allow DRBD to be used as the kernel module.
To close the week, Marius gave developers a helping hand in dealing with unreadable code. Following on from a prior post on PHP coding standards, he found that most tools which homogenise code tend to rigidly follow standards such as K&R and Allman. As a substitute he suggested Artistic Style (Astyle) for more freedom and speed in formatting code. Written in C++, it modifies the entire code base within seconds and allows the user to finely prescribe his own standards in configuration. Marius gave an example using Oracle’s Java coding conventions, and then used Astyle to apply his new standard to the relevant files.
Have a question or suggestion for any of our tips? Simply add a comment to the relevant post!
NETWAYS Blog
Apple Time Machine mit Netzwerk Share verwenden
Normalerweise kann die in Mac OS X integrierte Backup Software Time Machine nur auf lokal angeschlossene Festplatten oder auf die teure Hardwarelösung Time Capsule sichern. Es gibt jedoch einen Trick, mit dem man auch gemountete Shares eines Servers verwenden kann und dabei ist es ganz egal, ob es sich um Samba (SMB), NFS oder AFS Shares handelt.
Die folgende Anleitung bescheibt, wie es am besten gelingt:
- Zuerst muss man auf dem Mac einen versteckten Konfigurationsparameter setzen, damit Netzlaufwerke überhaupt in Time Machine angezeigt werden. Dazu ruft man das Terminal auf und gibt in das Fenster den folgenden Befehl in einer Zeile ein (am besten per Copy und Paste einfügen):
[code language=“shell“]defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1[/code] - Zum Speichern der Backup Dateien benutzt OS X ein sogenanntes Sparse Bundel, das auf einer lokalen USB Festplatte automatisch angelegt wird. Leider funktioniert das nicht auf dem Netzwerkshare und so muß man das Sparse Bundle manuell erzeugen. Dazu startet man das Festplattendienstprogramm und klickt anschließend auf den Button „Neues Image erstellen“:
- Im anschließenden Dialog gibt man zuerst einen Dateinamen, beispielsweise „timemachine“ und gibt als Speicherort den Schreibtisch an. Wir müssen die Datei später sowieso auf den Server verschieben. Als nächstes sollte man die letzte Option „Image-Format“ ändern (letzter Auswahlpunkt). Dieses Dropdown steht normalerweise auf „Beschreibbares Image“ und muß unbedingt auf „Mitwachsendes Bundle-Image“ geändert werden. Danach kann man noch eine maximale Größe für die Imagedatei angeben. Dieser Wert steht normalerweise auf 100MB, was natürlich viel zu wenig ist. Ich habe hier 300GB als Maximalwert angegeben. Gibt man nichts an, kann die Datei theoretisch so groß werden, wie Speicherplatz auf dem Server zur Verfügung steht. Am Anfang ist das Image ca. 150MB groß und wächst automatisch, bis das eingestellte Limit erreicht ist, danach fängt Time Machine an ältere Backups zu löschen. Optional kann man noch den Volumenamen setzen, so dass man das gemountete Image später leicht identifizieren kann. Hier ein Beispiel, wie ich meine Daten angegeben habe:
- Nach dem Klick auf „Erstellen“ generiert OS X die Datei, welche dann auf dem Schreibtisch liegt.
- Danach mounted man das Servershare, auf dem man seine Time Machine Backups speichern will und verschiebt die gerade erstellte Datei auf dieses Share.
- Dann kann man Time Machine zum ersten Mal starten. Man ruft also Time Machine in den Systemeinstellungen auf, gibt das gemountete Share als Backup Volumen an und konfiguriert seine Optionen. Insbesondere sollte man Verzeichnisse, die man nicht mehr extra sichern muss, aus dem Backup ausschließen. Bei mir sind das die Verzeichnisse Downloads, ein temporäres Verzeichnis, Filme und die Datenbankdatei von Entourage, weil meine E-Mails ja sowieso nochmal auf dem Server liegen.
- Anschließen kann man das erste Backup starten, allerdings sollte man dabei noch das gemountete Share im Finder geöffnet haben, denn Time Machine versucht nun eine eigene Sparsebundel Datei zu erstellen. Sobald die Datei im Finder erscheint, kopiert man sich den Namen per Copy und Paste in die Zwischenablage. Danach kann man das Backup gleich wieder abbrechen, denn es wird sowieso fehlschlagen, da die Bundle Datei nicht erfolgreich angelegt werden kann.
- Nun muss man nur noch die selbst erstellte Bundel Datei in den gerade per Copy und Paste gesicherten Namen umbenennen und das „tmp“ aus dem Namen entfernen. Aus „jhein MacBook_002500ac9213.tmp.sparsebundle“ wird also „jhein MacBook_002500ac9213.sparsebundle“. Alternativ kann man den Namen auch manuell vergeben, denn er besteht aus „Rechnername_MacAdresse.sparsebundle“
- Danach kann man Time Machine nochmal manuell starten und dieses mal sollte es fehlerfrei durchlaufen.
Der erste Durchlauf hat bei mir mit fast 120 GB zu sichernden Daten ein bisschen gedauert. Seit diesem ersten Start laufen alle nachfolgenden Backups aber schon seit mehreren Tagen schnell und vor allem fehlerfrei durch. Um das ganze zu testen habe ich einige Files wieder zurückgesichert, ohne dass Probleme aufgetreten sind.
Julian Hein
Executive Chairman
Julian ist Gründer und Eigentümer der NETWAYS Gruppe und kümmert sich um die strategische Ausrichtung des Unternehmens. Neben seinem technischen und betriebswirtschaftlichen Background ist Julian häufig auch kreativer Kopf und Namensgeber, beispielsweise auch für Icinga. Darüber hinaus ist er als CPO (Chief Plugin Officer) auch für die konzernweite Pluginstrategie verantwortlich und stösst regelmässig auf technische Herausforderungen, die sonst noch kein Mensch zuvor gesehen hat.
