Belanglosigkeiten aus meinem Leben
Unser bisheriger Router, ein DrayTek Vigor 2900G, ist abzugeben. Zu finden bei Amazon.
Das Gerät ist in sehr gepflegtem Zustand und bietet einen reichhaltigen Funktionsumfang (insb. bei Sicherheitsfunktionen) und ist damit genau das Richtige für Anwender, die mehr Qualität und Funktionen als die der üblichen Billiganbieter wünschen. Details zum Router gibts direkt bei DrayTek.
Siemens hat seine Gigaset-Tochter verkauft. Der Beweis, dass man mit Made-In-Germany-Produkten bei viel Billigkonkurrenz zumindest im eigenen Land unter den Marktführern sein kann, soll nicht mehr zu Siemens gehören. Siemens hat sich damit endgültig von seinen Wurzeln getrennt. Nokia stellt schließlich auch keine Gummistiefel mehr her. Der neue Besitzer ist verpflichtet, die Standorte in Bocholt und München drei Jahre lang zu erhalten.
Warum habe ich das Gefühl, dass ich jetzt schon weiß, was in drei Jahren oder weniger wieder von vorne los geht?
(Und manchmal frage ich mich, welche Qualifikationen man eigentlich mitbringen muss, um Top-Manager zu sein.)
Das hier ist übrigens das rappelnde Geräusch* meines MacBook Pro, von dem ich schrieb. Das Geräusch, was man beim Apple Service Provider übrigens nicht finden bzw. nachvollziehen konnte.
* Aufgenommen mit meinem Handy, daher sehr schlechte Tonqualität. Ich musste die Aufnahme nachträglich um 6 dB verstärken, aber das liegt alleine daran, dass das Handy erstens schlechte Aufnahmequalitäten hat und zweitens anscheinend eine Rauschunterdrückung das hier gewollte Rauschen abschwächt. Daher ist die Lautstärke nur bedingt aussagekräftig, das ungewöhnliche Klappern und Rappeln sollte aber deutlich hörbar sein.
Aufgenommen wurde das Lüftergeräusch bei einer Drehzahl von ca. 3000 U/min. Bei der Drehzahl sollte der Lüfter gerade hörbar, aber sehr leise und vor allem absolut gleichmäßig rauschen.
After two years my Nokia E70 showed first signs of fatigue. In the end the click of the 5 way stick did not work anymore. I assumed dust as cause and decided to open the phone. Opening it was a success although the stick still does not work. Despite that, if anyone wants to open his E70 there are some pictures I made at flickr. Click the image to see them.
Mein Nokia E70 zeigt nach fast zwei Jahren erste Ermüdungserscheinungen. Nachdem der Klick des 5-Wege-Sticks immer schwerer ging, fiel er vor kurzem komplett aus. Ich vermutete Staub als Ursache und entschloss mich, das Handy zu öffnen. Letzteres gelang, der Stick geht aber leider nach wie vor nicht. Trotz allem: Wer sein E70 mal öffnen will, bei flickr gibts von mir ein paar Fotos dazu. Mehr nach dem Klick auf das Bild.
(Dieser Artikel ist auch auf deutsch verfügbar.)
This article refers to a predecessor article concerning Time Machine backups on network shares in Leopard.
In the comments on this article a thread in Apple’s support forums was mentioned which describes problems with Time Machine and network shares (thanks to John M for that remark).
To explain the problem you need to be aware of how sparse bundle images (the ones Time Machine uses for network backups) work. Sparse bundle images and sparse images are special forms of disk images with certain advantages. To say it in simple terms a disk image is just a file that is treated like a drive (e. g. a hard disk). The image file is contained in a real drive (locally or on the network) which I will call container.
You can mount the image and use it like a real drive. Mac OS X takes care of writing the data into the image file. In the simplest case the image is a file that has exactly the size of the virtual drive’s maximum capacity. If you create an image with 100 GB capacity you will have a 100 GB file even if the image only contains some MB of data.
And here the sparse images come into play. They occupy only the space the data in the image occupies. Therefore, you can create an image with 100 GB capacity which as a file is only a few MB big. The image file grows as it is filled with data.
However, there is a catch in it. Deleting files in the image does not result in a smaller image file. For example: If you create a 10 GB file in the image the image file will increase to a size of 10 GB as well. Free space in the image will be 90 GB. Afterwards you delete the file and the free space in the image will be 100 GB again. Without further intervention the image file however will keep its size of 10 GB*. Inside the image everything is in order. Thus, while using the image its file will at most keep its size, mostly grow in size (due to creating further files in the image), but never shrink by itself. This is one part of the problem.
The other part of the problem is a behaviour of Mac OS X which is actually really useful. Mac OS X does not prevent the user from creating a sparse image with a maximum capacity bigger than the free space or even the maximum capacity of the container. This may turn out to be a problem. For example take our fresh image with 100 GB capacity. Assume its in a container with 20 GB free space. The user might want to create a 30 GB file in the image which naturally will not work.
Mac OS X acts rather clever here. If an image is mounted Mac OS X checks how much free space is available in the container (here 20 GB). If this value is smaller than the theoretically free space in the image (here approx. 100 GB) Mac OS X will limit the free space in the image to the free space of the container. In our example: The image has a maximum capacity of 100 GB and 20 GB free space even if there are no files on the image!
In itself this behaviour makes sense. In combination with Time Machine it can lead to fatal consequences. For example: In our previously mentioned image you create an 18 GB file. The image file will grow to a size of 18 GB. Afterwards free space in the container and the image will be 2 GB. Now you delete the 18 GB file. Theoretically the free space in the image will increase by 18 GB.
Now both above mentioned effects come into play. The image file will keep its size of approx. 18 GB. Hence the free space in the container will still be 2 GB. Therefore, the free size in the image will as well be only 2 GB. In this case deleting a file in the image does not create further free space in it. If you want to create a new 18 GB file Mac OS X will not allow that. The problem can be avoided by always keeping enough free space in the container. In our case we would have to free at least 16 GB in the container*.
Assume in our initial situation above free space in the container would not be 20 GB but 120 GB. Mac OS X will then always specify the free space regarding only the image (100 GB capacity). Deleting the 18 GB file will indeed increase the free space to 100 GB. This also shows how fatal it is, if the maximum capacity (or the maximum free space respectively) of the container is less than the capacity of the image. In this case the free space of the image will always be specified regarding the container. At some point the image will become unusable because the image file grows inexorably while the apparent free space of the image shrinks.
This is exactly the trap Time Machine falls into, if you do not pay attention to the free space on the network drive. Assume the Time Machine image has less free space than the next backup needs. Time Machine will then automatically delete old backups to free up some additional space. If the free space on the network share is greater than that in the image (i. e. the free space in the image is not affected by the free space in the container) everything will work smoothly. With every deleted old backup the free size in the image will grow a little.
However, if the free size in the image is limited by the container deleting backups will not create additional free space. Time Machine will futilely keep on deleting all backups but the last one in order to clear space. Afterwards it will fail due to lack of free space (like in the above mentioned support thread).
Possible trouble-shootings:
Disclaimer: I have never experienced these problems in Time Machine myself. Therefore, I cannot guarantee that the above stated solutions actually work. In my case there is enough free space on the network share so that backups are created smoothly. Your own reports and experiences are very appreciated.
You should always be aware that Time Machine backups on network shares are not officially supported by Mac OS X (except Time Capsule). In doubt you should not trust a solution like this.
* There is a possibility to reclaim unoccupied space via hdiutil. However, as Time Machine does not utilize it I will ignore this possibility here.
(This article is also available in English.)
Dieser Artikel bezieht sich auf einen Vorgängerartikel zum Thema Time-Machine-Backups auf Netzwerkfreigaben unter Leopard.
Aus den Kommentaren in der englischen Version des ersten Artikels kam ein Hinweis auf einen Thread in Apples Supportforen, der auf ein Problem mit Time Machine und Netzwerkfreigaben hinweist (Danke an John M dafür).
Um das Problem zu erklären muss man sich jedoch erst klar machen, wie Bundle-Images (die Time Machine für Netzwerk-Backups verwendet) funktionieren. Sparse-Bundle-Images („mitwachsendes Bundle-Image“) und Sparse-Images („mitwachsendes Image“) sind spezielle Formen eines Disk-Images mit bestimmten Vorteilen. Ein Disk-Image ist vereinfacht gesagt nur eine Datei, die wie ein Laufwerk (z. B. eine Festplatte) behandelt wird. Die Image-Datei liegt auf einem echten Laufwerk (lokal oder im Netz), dass ich als Container bezeichnen werde.
Das Image kann man ins System einbinden („mounten“) und dann wie ein Laufwerk verwenden. Mac OS X kümmert sich darum, die Daten in die Image-Datei zu schreiben. Prinzipiell ist ein Image also im einfachsten Fall eine Datei, die genauso groß ist, wie die Maximalgröße des virtuellen Laufwerks. Erstellt man also ein Disk Image mit 100 GB Kapazität, hat man eine 100 GB große Datei, selbst wenn im Image nur wenige MB belegt sind.
Und hier kommen die Sparse-Images ins Spiel. Diese belegen nur den Platz, den auch die Daten im Image belegen. Man kann also ein Image mit 100 GB Kapazität erstellen, das als Datei nur wenige MB groß ist. Erst wenn das Image mit Daten gefüllt wird, wächst auch die Image-Datei.
Allerdings hat die Sache einen Haken. Das Löschen von Daten im Image sorgt nicht dafür, dass die Image-Datei kleiner wird. Anschaulich: Erstelle ich im Image eine 10 GB große Datei, wird die Image-Datei 10 GB groß, der freie Speicher im Image beträgt 90 GB. Lösche ich die Datei anschließend, sind im Image wieder die kompletten 100 GB frei. Die Image-Datei selber behält aber ohne Weiteres ihre Größe von 10 GB*. Innerhalb des Images ist also alles in Ordnung. Durch Benutzung des Images wird die dazugehörige Datei selbst höchstens gleich groß bleiben, meistens wachsen (indem weitere Dateien im Image erstellt werden), aber von alleine nie kleiner werden. Dies ist ein Teil des Problems.
Der andere Teil liegt in einem Verhalten vom Mac OS X, das sonst eigentlich sehr nützlich ist. Mac OS X hindert den Nutzer nicht, ein Sparse-Image zu erstellen, dessen Maximalkapazität den freien Platz oder gar die Maximalkapazität des Containers überschreitet. Prinzipiell ist das natürlich ein Problem. Nehmen wir unser frisches Image mit 100 GB Kapazität. Dieses liege in einem Container mit 20 GB freiem Speicher. Im Image könnte der Benutzer nun eine 30 GB große Datei erstellen wollen, was natürlich nicht funktionieren kann.
Hier verhält sich Mac OS X vergleichsweise schlau. Wird ein Image gemountet, prüft Mac OS X wie viel Platz im Container frei ist (hier 20 GB). Ist dieser Wert kleiner als der formal freie Platz im Image (hier ca. 100 GB), so wird Mac OS X den freien Speicher im Image auf den freien Speicher im Container begrenzen. In unserem Beispiel: Das Image hätte eine Maximalkapazität von 100 GB und 20 GB freien Speicher. Und das, obwohl auf dem Image noch gar keine Daten liegen!
An sich ist dieses Verhalten sinnvoll, im Zusammenspiel mit Time Machine jedoch kann es fatale Folgen haben. Angenommen wir erstellen im obigen Image eine 18 GB große Datei. Die Image-Datei wird auf 18 GB anwachsen, im Container wie auch im Image sind anschließend nur noch 2 GB frei. Jetzt löschen wir die 18 GB große Datei wieder. Im Image werden dadurch formal 18 GB frei.
Aber nun kommen die beiden obigen Effekte ins Spiel. Die Image-Datei wird ihre Größe von ca. 18 GB behalten. Im Container sind daher nur 2 GB frei. Also sind auch im Image nur 2 GB frei. Das Löschen der Datei im Image hat also keinen zusätzlichen Platz geschaffen. Möchten wir nun erneut eine 18 GB große Datei erstellen, wird Mac OS X dies nicht erlauben. Umgehen lässt sich das Problem, wenn im Container immer genug freier Speicher verfügbar ist. In unserem Fall müssten wir also dort mindestens 16 GB frei machen*.
Haben wir in der obigen Ausgangssituation im Container nicht 20 GB sondern 120 GB frei, wird sich Mac OS X beim freien Speicher immer am Image orientieren. Das Löschen der 18 GB großen Datei wird also tatsächlich dazu führen, dass im Image wieder 100 GB Speicher frei werden. Hier zeigt sich auch, wie fatal es ist, wenn die Maximalkapazität (bzw. der maximale freie Speicher) des Containers kleiner als die Kapazität des Images ist. In diesem Fall wird sich der freie Speicher immer am Container orientieren. Das Image wird irgendwann unbrauchbar, weil die Image-Datei immer weiter anwächst und damit der scheinbar freie Speicher im Image immer kleiner wird.
In genau diese Falle tappt Time Machine, wenn man beim freien Speicher auf dem Netzlaufwerk nicht aufpasst. Angenommen im Time-Machine-Image ist weniger Platz verfügbar als Time Machine für das nächste Backup benötigt. Time Machine wird dann automatisch alte Backups löschen, um zusätzlichen Platz zu schaffen. Ist auf dem Netzlaufwerk mehr freier Speicher verfügbar als im Image (d.h. ist der freie Speicher im Image nicht vom Container betroffen), läuft alles problemlos. Durch jedes gelöschte alte Backup wird im Image etwas mehr Speicher frei.
Ist aber der freie Speicher im Image durch den Container begrenzt, wird das Löschen eines Backups keinen zusätzlichen Speicher verfügbar machen. Time Machine wird dann alle Backups bis auf das letzte löschen und anschließend das Backup wegen Speichermangel abbrechen (wie im o. g. Apple-Support-Thread).
Mögliche Lösungen für dieses Problem:
Disclaimer: Ich selber habe diese Probleme nie im Zusammenhang mit Time Machine erlebt und kann daher auch nicht garantieren, dass obige Lösungen wirklich funktionieren. Hier ist momentan genug Speicher auf der Netzfreigabe verfügbar, so dass Backups problemlos erstellt werden. Für Praxisberichte und Erfahrungen wäre ich dankbar.
Man sollte sich auch dessen bewusst sein, dass Time Machine Backups auf Netzwerkfreigaben (Time Capsule ausgenommen) nicht von Mac OS X unterstützt werden. Im Zweifel sollte man einer solchen Lösung also nicht vertrauen.
* Es gibt auch die Möglichkeit, per hdiutil den unbelegten Speicher wieder freizugeben. Diese Möglichkeit nutzt Time Machine (um die es hier geht) jedoch nicht von alleine, weswegen ich diese Möglichkeit außen vor lasse.
Seitdem auf meinem Notebook Mac OS X Leopard (10.5) läuft, habe ich einen neuen Lieblingsbrowser. Nachdem ich mich immer mehr geärgert hatte, hab ich mich endlich vom Firefox getrennt. Die Gründe dafür sind vielfältig, kann ich bei Interesse gerne erläutern, gehören aber jetzt nicht hier her.
Safari hat in der aktuellen Version 3 endlich Features bekommen, die bisher den Wechsel von Firefox ausschlossen. Aber inzwischen kann Safari mehrere Tabs als Bookmarks speichern, im Gegensatz zu Firefox nach dem Beenden komplette Sessions zuverlässig wiederherstellen und für mich am wichtigsten den Benutzer warnen, wenn er (womöglich ausversehen) ein Fenster mit mehreren Tabs schließen will. Letzteres ist eine totale Kleinigkeit, für mich aber eine essentielle Funktion, ohne die ich mich schon mehrfach extrem aufgeregt hätte (ich habe oft 10-30 Tabs in einem Fenster offen, da ist das extrem blöd, wenn das alles weg ist).
Johnny hat sich drüben bei MobileMacs mal über Bediener-Ärgernisse bei Apple aufgeregt. Während ich das dort aber eher als ärgerliche Kleinigkeiten abtun würde, macht Safari bzw. Mac OS X generell etwas wirklich total Unsinniges.
Drückt man Command-W, schließt Safari den aktuellen Tab. Command-Shift-W schließt das gesamte Fenster, ggf. mit Nachfrage. Und wenn man einmal abrutscht, und Command-Alt-W in einem Fenster ohne Tabs drückt? Dann schließt Safari bzw. Mac OS alle offenen Fenster von Safari. Ohne Nachfrage.*
Größere Recherche gemacht? Pech gehabt. Gerade in einem weiteren Fenster eine E-Mail im Webmailer angefangen? Pech gehabt. Ausversehen die falsche Taste gedrückt? Pech gehabt.
Glücklicherweise konnte ich Quicksilver dazu überreden, Command-Alt-W systemweit abzufangen. Drücke ich diese Kombination, passiert Folgendes:
Damit ich mich dann auch immer wieder an diese Bedienfreundlichkeit erinnern darf.
* Drückt man Command-Alt-W in einem Fenster mit Tabs, schließt Safari nur alle Tabs in dem Fenster, auch ohne Nachfrage. Zur Konsistenz dieser Bedienung muss man nichts sagen, oder?
This is a slightly shortened version of an article I already wrote in German which is my native language so please forgive me possible mistakes.
Mac OS X features in its newest release Leopard (Mac OS X 10.5.2 while I am writing this) an automatic backup solution called Time Machine. It automatically creates backups, takes care of everything and even incorporates a very stylish interface to find and recover old files.
Unfortunately Time Machine has some limitations. So far it only works with external hard disks that are connected directly to the Mac. Apple now provides a solution for network backups called Time Capsule. However, using already existing drives for backup would be desirable.
You can find guides to make Time Machine at least accept network shares as backup drives in the web. Using the command (all in one line)
defaults write com.apple.systempreferences
TMShowUnsupportedNetworkVolumes 1
in Terminal is sufficient. But this only results in accepting the share. At least in my case creating the first backup failed with the error:
Time Machine Error - The backup disk image could not be created.
Pretty dissatisfactory. We gonna need new solutions. In my investigation I often found the statement that Time Machine simply would accept self made disk images on the network share. It doesn’t.
It rather helps to investigate the failed backup attempt more precisely. You will notice that Time Machine tries to create a sparse bundle disk image on the share. It remains Time Machine’s mystery why that fails.
On Apple’s support forums you’ll find further advice. It is proposed to copy the bundle image while creation and to copy it back after this fails. Did not work for me. Anyway, the solution is much simpler. During the backup attempt Time Machine creates the bundle image on the share. This is called <computer’s name>_<string>.sparsebundle (Update: by the way, string is the MAC address of the local en0 device without colons). You should keep the exact name in mind (e.g. by copy & paste or by looking in Console or by constructing it yourself from computer’s name and MAC address).
Afterwards you start Disk Utility and create another “sparse bundle disk image” on your local drive. Volume Size should be the designated maximum size (see update 2) of the Time Machine backup (don’t be afraid, only by using the image it will increase in size). Further parameters: Volume Format - Mac OS Extended (Journaled); Partitions - No partition map.
After this use the exact name Time Machine assigned to its bundle image to rename your newly created image (if not already done while creating your own image). Finally you copy the image on the share and manually start a backup via menu bar.
Voilà. Afterwards Time Machine should start the tedious initial backup.
Update: Giving it a try I am positively surprised. After the successful initial backup Time Machine tries to create new backups every hour. And doing so it behaves very ideally. If the network share is not accessible (e.g. host is turned off) the backup simply will not be performed (and the user won’t be bugged with error messages). Nevertheless Time Machine continues to try to access it hourly. If the host comes online again new backups will be created. The needed share and disk image will be mounted automatically.
If you want to access Time Machine to recover files the automatic mounting will work as well. At first (in my case) the Spotlight index was broken. I don’t know why this happened, but I have created an article how to repair this index (currently only available in German).
On the network host which provides the share I have created a special backup user whose home directory contains the image. Fortunately, Time Machine has no problem if a user connects to shares on the host with his own user data.
Let’s face the drawbacks. Once a backup is created or Time Machine is launched the image will indeed be mounted but will not always be unmounted afterwards. Thus, users will have the image on their desktops. The connection to the share itself will also be kept established (but it is only visible by entering mount in Terminal).
Both isn’t necessarily bad if the share keeps being available. However, this does not have to be the case. If you want to disconnect image and share correctly from your Mac you’ll first have to unmount the image itself. Sometimes the system requires an admin password to do so. The share can only be unmounted by calling umount in Terminal. Supposably it will become problematic if the host is shut down while a connection is established or even a backup is in progress.
And of course bandwidth is a major drawback. If (as in my case) the Mac is a MacBook primarily using 802.11g WLAN and accessing the share on a Windows machine via SMB you surely should not expect too much from this solution.
Update 2: Things you should know about the maximum size of the image and the free space on the network share.
Schon wieder ein Technikartikel. Irgendwie habe ich es gestern geschafft, den Spotlight-Index sowohl auf meiner eigenen Time-Machine-Backup-Platte, sowie auf dem im vorigen Artikel beschriebenen Netzwerk-Backup-Image zu zerschießen. Das machte sich dann u. A. darin bemerkbar, dass Spotlight in den Backups keine Dateiinhalte mehr fand, die definitiv vorhanden waren.
Ärgerlich, dass sowas überhaupt passiert. Aber noch ärgerlicher, dass übliche Problembeseitigungsvorschläge bei mir nichts brachten. Diese sehen z. B. vor, per mdutil den Index neu zu erstellen. Dazu gibt man mit root-Rechten oder per vorangestelltem sudo im Terminal ein:
mdutil -E /Volumes/<Volumename>
Dies führte zwar in meinem Fall dazu, dass Spotlight begann, den Index neu zu erstellen. Allerdings war dieser Vorgang nach Sekunden (im Fall des mit 19 GB belegten Images) bis wenigen Minuten (im Fall meiner externen Platte, die immerhin 164 GB an Backups enthält) beendet, was definitiv zu schnell ist, um eine so große Datenmenge zu indizieren.
Was dagegen half: Über das Terminal auf dem betreffenden Volume den Ordner .Spotlight-V100 löschen:
rm -r /Volumes/<Volumename>/.Spotlight-V100
Anschließend ließ sich dann mit obigem Befehl der Index wirklich neu erstellen. Das dauerte im Fall der externen Platte einige Stunden. Beim Backup-Image, das noch sehr frisch ist, ging es wesentlich schneller.
Jetzt funktioniert die praktische Suche auch in Time Machine wieder. Und ich hoffe, dass so ein kaputter Index nicht so schnell wieder vorkommt.
Aktuelle Kommentare