-
Apfeltalk ändert einen Teil seiner Allgemeinen Geschäftsbedingungen (AGB), das Löschen von Useraccounts betreffend.
Näheres könnt Ihr hier nachlesen: AGB-Änderung -
Was gibt es Schöneres als den Mai draußen in der Natur mit allen Sinnen zu genießen? Lasst uns teilhaben an Euren Erlebnissen und macht mit beim Thema des Monats Da blüht uns was! ---> Klick
MasterBootRecord Partitionstabelle -- Ändern der Partition möglich?
- Ersteller simmac
- Erstellt am
- Registriert
- 22.03.11
- Beiträge
- 2.482
wie kopieren?
Ich habe jetzt doch die Möglichkeit, eine 1tb Festplatte auf der noch genügend Speicherplatz frei ist, Zu benutzen.
Kann ich einfach den Ordner backup.backupd auf die zwei fest platte ziehen, die jetzige im GUID neu formatieren und zurück kopieren ohne dass ich Probleme mit alten oder zukünftigen backups habe?
[EDIT]: ich habe auf der backup-platte auch backups von einem zweitcomputer, welche allerdings so klein sind, dass ich den zugehörigen Ordner in der backup.backupd problemlos auf die interne Festplatte dieses computers kopieren kann.
Mfg
SimMac
Ich habe jetzt doch die Möglichkeit, eine 1tb Festplatte auf der noch genügend Speicherplatz frei ist, Zu benutzen.
Kann ich einfach den Ordner backup.backupd auf die zwei fest platte ziehen, die jetzige im GUID neu formatieren und zurück kopieren ohne dass ich Probleme mit alten oder zukünftigen backups habe?
[EDIT]: ich habe auf der backup-platte auch backups von einem zweitcomputer, welche allerdings so klein sind, dass ich den zugehörigen Ordner in der backup.backupd problemlos auf die interne Festplatte dieses computers kopieren kann.
Mfg
SimMac
Zuletzt bearbeitet:
Wenn eine Backups-Datenbank kopiert werden soll ohne sie zu verhunzen (oder zumindest einige Ungenauigkeiten zu verursachen), müssen dabei einige Dinge sichergestellt sein:
- Während dieser lange dauernden Kopie dürfen keine neuen Einträge entstehen, die Automatik muss also zumindest vorher auf "Aus" gestellt werden. Noch besser ist es, TM vorübergehend gleich ganz stillzulegen indem man als Sicherungsvolume "Ohne" einstellt.
- Wenn das Quellvolume mit aktiver Gross/Kleinschreibung formatiert wurde, muss auch das Ziel so eingerichtet sein.
Für die spätere Kopie wieder zurück gilt dann natürlich das gleiche.
(Eine Migration "zurück" zu einem normalen Volume ist nur möglich, wenn diese Funktion in keinem einzigen der vielen von TM gesicherten Ordner jemals tatsächlich zur Verwendung kam, dazu s.u. bei 'ditto')
- Auf dem Zielvolume darf es noch keine andere Backup-Datenbank geben. Zwei Sicherungsserien zusammen auf ein Volume zu bringen (also "ineinander zu mischen") ist nur in der Theorie möglich. Praktisch wäre der Vorgang so komplex dass du damit rechnen kannst, seine Beendigung u.U. nicht mehr zu erleben.
- Um die Eigentümer der gesicherten Objekte exakt beizubehalten und eine optimal kompakte Kopie zu erzeugen, empfiehlt es sich für den Vorgang nicht den Finder zu verwenden sondern einen der beiden folgenden Wege:
a) Die Funktion "Wiederherstellen" des Festplattendienstprogramms. Das ist der empfohlene, schnellste und einfachste Weg.
Nachteil: Das Zielvolume muss komplett gelöscht werden bevor die Kopie beginnen kann (wird automatisch erledigt wenn in SnowLeopard die entsprechende Checkbox gesetzt wird, ab Lion geschieht das sowieso immer).
Wenn das kein Problem darstellt, sollte diese Methode benutzt werden. Geht so simpel dass man wohl nichts weiteres dazu erklären muss.
b) Mittels Terminal (als ein Administrator)
Ein in jeder Hinsicht und jedem Detail perfekter Klon einer TM-Sicherung lässt sich nur mit zwei verfügbaren Tools erstellen, das sind "asr" und "ditto" (andere Kopierbefehle wie 'cp' oder 'rsync' dürfen keinesfalls benutzt werden!).
'asr' ist genau das Tool, das technisch gesehen hinter der bereits beschriebenen 'Wiederherstellung' steckt, das zu beschreiben ist also überflüssig.
'ditto' ist ein sehr mächtiges und zuverlässiges Kopierwerkzeug, damit es korrekte Ergebnisse erzielen kann muss es aber auch präzise angewandt werden, und dazu muss man vorher die geeigneten Bedingungen schaffen. Das ist extrem wichtig. Wer diese Fallstricke kennt und beherzigt, der kann auf diesem Weg einfach alles klonen, auch bootfähige Startvolumes oder komplex konfigurierte Serverumgebungen. Wer sie missachtet, kopiert dagegen zwangsläufig nur nutzlosen Müll.
--how2use ditto--
1) Sowohl beim Quell- als auch beim Zielvolume muss sichergestellt sein, dass die Dateieigentümer korrekt wiedergegeben und respektiert werden. Da das bei extern verbundenen HFS-Volumes auf "ignorieren" voreingestellt ist, muss das (mit Admin-Privilegien) meist erst so eingestellt werden. Das geht entweder über die entsprechende Checkbox in den Finder-Informationen oder ganz einfach über den folgenden Terminalbefehl (jeweils einmal pro Volume):
Den richtigen Mountpoint kann man dabei ganz einfach einfügen, indem das Volume per Drag&Drop vom Finder ins Terminalfenster gezogen wird. (Das funktioniert mit nahezu allen Finder-Objekten, an der aktuellen Cursorposition wird automatisch der korrekt ausgeschriebene Pfad eingesetzt.)
Um sicherzustellen dass die Änderung auf jeden Fall wirksam wurde, sollte das Volume danach getrennt und erneut verbunden werden.
Hier sei angemerkt, dass in SnowLeopard im Festplatten-DP diese Einstellung grundsätzlich falsch angezeigt wird!
Nicht glauben was dort unter "Eigentümer aktiviert" steht!
2) Jetzt kann die Kopie beginnen.
Weil ein jeder TM-Sicherungsordner durch den Kernel mit einem besonderen Schutzmechanismus behütet wird, der unbefugte Schreibzugriffe radikal stoppt (was beim Zielordner fatal wäre), muss dieser Mechanismus mit einer speziellen Vorgehensweise in mehreren Schritten ausgetrixxt werden. (Ansonsten kann es mitten in der Kopie zu einem "unerklärlichen" Abbruch der Kopie kommen.)
Wichtig:
Bis diese Prozedur vollständig beendet und dieser besondere TM-Schutz als letzter Schritt "scharf geschaltet" wurde, darf keinesfalls mit dem Finder oder anderen Programmen in der gerade neu entstehenden Kopie herumgestöbert werden. Auch nicht "nur ganz kurz mal eben nachsehen".
Das würde evtl schon zu einer unerwünschten Verfälschung des Ergebnisses führen.
Zunächst wird der alte Ordner in einen neuen Ordner umkopiert, der für den Kernel nur als "ganz gewöhnlicher" Ordner aussieht. Das ist ziemlich einfach, der Zielordner darf nur ganz einfach nicht das entscheidende Namenssuffix '*.backupdb' erhalten.
Dann wird eine Synchronisierung des RAM-Cache mit der HD erzwungen, erst dann wird der Zielordner endgültig "versiegelt" indem ganz einfach nur dieses besondere Suffix hinzugefügt wird.
Auch hier kann wieder ganz bequem Drag&Drop eingesetzt werden.
(Achte besonders auf die korrekte Gross/kleinschreibung bei allen Terminalkommandos und ihren Parametern !!! ):
Jetzt sind sowohl Quell- als auch Zielvolume auszuwerfen, dann nur das Zielvolume wieder zu aktivieren und in der TM-Systemeinstellung dieses neue Ziel als Target einzustellen. Jetzt muss noch (manuell) ein neuer Backuplauf angestossen werden, danach ist die Normalität wiederhergestellt und das alte Backup-Volume kann nach Bedarf beseitigt werden.
- Während dieser lange dauernden Kopie dürfen keine neuen Einträge entstehen, die Automatik muss also zumindest vorher auf "Aus" gestellt werden. Noch besser ist es, TM vorübergehend gleich ganz stillzulegen indem man als Sicherungsvolume "Ohne" einstellt.
- Wenn das Quellvolume mit aktiver Gross/Kleinschreibung formatiert wurde, muss auch das Ziel so eingerichtet sein.
Für die spätere Kopie wieder zurück gilt dann natürlich das gleiche.
(Eine Migration "zurück" zu einem normalen Volume ist nur möglich, wenn diese Funktion in keinem einzigen der vielen von TM gesicherten Ordner jemals tatsächlich zur Verwendung kam, dazu s.u. bei 'ditto')
- Auf dem Zielvolume darf es noch keine andere Backup-Datenbank geben. Zwei Sicherungsserien zusammen auf ein Volume zu bringen (also "ineinander zu mischen") ist nur in der Theorie möglich. Praktisch wäre der Vorgang so komplex dass du damit rechnen kannst, seine Beendigung u.U. nicht mehr zu erleben.
- Um die Eigentümer der gesicherten Objekte exakt beizubehalten und eine optimal kompakte Kopie zu erzeugen, empfiehlt es sich für den Vorgang nicht den Finder zu verwenden sondern einen der beiden folgenden Wege:
a) Die Funktion "Wiederherstellen" des Festplattendienstprogramms. Das ist der empfohlene, schnellste und einfachste Weg.
Nachteil: Das Zielvolume muss komplett gelöscht werden bevor die Kopie beginnen kann (wird automatisch erledigt wenn in SnowLeopard die entsprechende Checkbox gesetzt wird, ab Lion geschieht das sowieso immer).
Wenn das kein Problem darstellt, sollte diese Methode benutzt werden. Geht so simpel dass man wohl nichts weiteres dazu erklären muss.
b) Mittels Terminal (als ein Administrator)
Ein in jeder Hinsicht und jedem Detail perfekter Klon einer TM-Sicherung lässt sich nur mit zwei verfügbaren Tools erstellen, das sind "asr" und "ditto" (andere Kopierbefehle wie 'cp' oder 'rsync' dürfen keinesfalls benutzt werden!).
'asr' ist genau das Tool, das technisch gesehen hinter der bereits beschriebenen 'Wiederherstellung' steckt, das zu beschreiben ist also überflüssig.
'ditto' ist ein sehr mächtiges und zuverlässiges Kopierwerkzeug, damit es korrekte Ergebnisse erzielen kann muss es aber auch präzise angewandt werden, und dazu muss man vorher die geeigneten Bedingungen schaffen. Das ist extrem wichtig. Wer diese Fallstricke kennt und beherzigt, der kann auf diesem Weg einfach alles klonen, auch bootfähige Startvolumes oder komplex konfigurierte Serverumgebungen. Wer sie missachtet, kopiert dagegen zwangsläufig nur nutzlosen Müll.
--how2use ditto--
1) Sowohl beim Quell- als auch beim Zielvolume muss sichergestellt sein, dass die Dateieigentümer korrekt wiedergegeben und respektiert werden. Da das bei extern verbundenen HFS-Volumes auf "ignorieren" voreingestellt ist, muss das (mit Admin-Privilegien) meist erst so eingestellt werden. Das geht entweder über die entsprechende Checkbox in den Finder-Informationen oder ganz einfach über den folgenden Terminalbefehl (jeweils einmal pro Volume):
Code:
sudo diskutil enableOwnership [I][COLOR="#0000FF"]Mountpoint[/COLOR][/I]Um sicherzustellen dass die Änderung auf jeden Fall wirksam wurde, sollte das Volume danach getrennt und erneut verbunden werden.
Hier sei angemerkt, dass in SnowLeopard im Festplatten-DP diese Einstellung grundsätzlich falsch angezeigt wird!
Nicht glauben was dort unter "Eigentümer aktiviert" steht!
2) Jetzt kann die Kopie beginnen.
Weil ein jeder TM-Sicherungsordner durch den Kernel mit einem besonderen Schutzmechanismus behütet wird, der unbefugte Schreibzugriffe radikal stoppt (was beim Zielordner fatal wäre), muss dieser Mechanismus mit einer speziellen Vorgehensweise in mehreren Schritten ausgetrixxt werden. (Ansonsten kann es mitten in der Kopie zu einem "unerklärlichen" Abbruch der Kopie kommen.)
Wichtig:
Bis diese Prozedur vollständig beendet und dieser besondere TM-Schutz als letzter Schritt "scharf geschaltet" wurde, darf keinesfalls mit dem Finder oder anderen Programmen in der gerade neu entstehenden Kopie herumgestöbert werden. Auch nicht "nur ganz kurz mal eben nachsehen".
Das würde evtl schon zu einer unerwünschten Verfälschung des Ergebnisses führen.
Zunächst wird der alte Ordner in einen neuen Ordner umkopiert, der für den Kernel nur als "ganz gewöhnlicher" Ordner aussieht. Das ist ziemlich einfach, der Zielordner darf nur ganz einfach nicht das entscheidende Namenssuffix '*.backupdb' erhalten.
Dann wird eine Synchronisierung des RAM-Cache mit der HD erzwungen, erst dann wird der Zielordner endgültig "versiegelt" indem ganz einfach nur dieses besondere Suffix hinzugefügt wird.
Auch hier kann wieder ganz bequem Drag&Drop eingesetzt werden.
(Achte besonders auf die korrekte Gross/kleinschreibung bei allen Terminalkommandos und ihren Parametern !!! ):
Code:
sudo ditto -vX --nocache [I][COLOR="#006400"]/Volumes/Backups/Backups.backupdb[/COLOR] [COLOR="#0000CD"]/Volumes/TM_Kopie/Backups.temp[/COLOR][/I]
sync
sudo mv [I][COLOR="#0000CD"]/Volumes/TM_Kopie/Backups.temp[/COLOR] [COLOR="#8B4513"]/Volumes/TM_Kopie/Backups.backupdb[/COLOR][/I]
Lieber nicht.
Das "verschieben" wäre mit dem beschriebenen Suffix-Trick möglich.
(Dazu MUSS unbedingt TM komplett ausgeschaltet sein und das Volume neu gemountet werden).
Aber ist nicht ratsam. Die Summe der verlinkten Objekte kann bei gut gefüllten Backups derart anwachsen dass es dir den Verzeichnisbaum des Volumes verbiegt. Dann hast du gleich zwei korrupte Backup-Serien. Genau genommen sogar drei.
Wie gesagt - geht, aber... hmmmm. Machs nicht. Das sind *Backups*, keine gebrauchten Zahnstocher.
(Das mit der sehr hohen Anzahl an Objekten ist auch der Grund, warum du kein Backup auf eine Startplatte legen, und auch keine Systemsoftware auf ein TM-Volume installieren darfst. Die haben sich bei dieser "blöden" Beschränkung schon was gedacht...)
- Registriert
- 22.03.11
- Beiträge
- 2.482
Ok, hat sich wohl erledigt:-[
Festplatte hat sich noch VOR dem Kopiervorgang mit einem Rhytmischen klacken verabschiedet:-c
Das wars dann wohl, obwohl ich die Platte erst ein gutes halbes Jahr habe...
Die Partitionen werden kurz erkannt, dann beginnt das Klacken und Finder/FP-DP (je nachdem was alles geöffnet war) reagieren nicht mehr und ich muss die Platte abstecken und Finder neu starten / FP-DP sofort beenden...
Festplatte hat sich noch VOR dem Kopiervorgang mit einem Rhytmischen klacken verabschiedet:-c
Das wars dann wohl, obwohl ich die Platte erst ein gutes halbes Jahr habe...
Die Partitionen werden kurz erkannt, dann beginnt das Klacken und Finder/FP-DP (je nachdem was alles geöffnet war) reagieren nicht mehr und ich muss die Platte abstecken und Finder neu starten / FP-DP sofort beenden...
Könnte auch nur eine mangelnde Versorgung mit nahrhaftem elektrischem Strom sein.
Externe Netzteile sind - sofern eins vorhanden/vorgesehen ist- kein reiner Dekorationsartikel.
Externe Netzteile sind - sofern eins vorhanden/vorgesehen ist- kein reiner Dekorationsartikel.
Ääähm. Mea culpa.
Mir ist da noch was eisenbiegerisch wichtiges eingefallen.
Lad dir das Skript in einer überarbeiteten Version noch mal und verwende dieses.
(Nicht schlimm, aber das andere funktioniert u.U. nicht wie erwartet.)
Falls das erste bei dir schon funktioniert hat, hat sich das erledigt.
Anhang anzeigen hd_modpatch2.zip
Mir ist da noch was eisenbiegerisch wichtiges eingefallen.
Lad dir das Skript in einer überarbeiteten Version noch mal und verwende dieses.
(Nicht schlimm, aber das andere funktioniert u.U. nicht wie erwartet.)
Falls das erste bei dir schon funktioniert hat, hat sich das erledigt.
Anhang anzeigen hd_modpatch2.zip
Nein.
Und wie könnte es denn wenns noch gar nicht gelaufen ist, durch Telepathie?
Kopieren TM-Backup von case-sensitive zu case-insensitiver HD
Ich hatte folgende Situation:
- Quelllaufwerk: Externes Laufwerk mit altem TM-Backup. Leider Case-sensitive formatiert. Die auf diesem Laufwerk gesicherten Daten stammen alle von der internen Macintosh HD, welche Journaled, d.h. also case-insensitive, formatiert ist (und immer war). Die oben genannte Bedingung, dass "diese Funktion [case-sensitive] in keinem einzigen der vielen von TM gesicherten Ordner jemals tatsächlich zur Verwendung kam", ist also eigentlich gegeben.
- Ziellaufwerk: Neues Laufwerk für neues TM-Backup. Möchte es nicht mehr case-sensitive haben, daher case-insensitive formatiert.
Das funktioniert im vorliegenden Fall leider nicht. ditto meldet beim Kopieren jedes symlinks innerhalb der Backups.backupdb "Operation not supported".
Ich hatte Deinen Text so verstanden, dass eine "Migration 'zurück' zu einem normalen Volume" (das heisst: Kopie der Backups.backupdb von einem case-sensitive zu einem case-insensitive Laufwerk) mit ditto möglich sein sollte, wenn - klar - die bisher gebackuppte Platte nie case-sensitive war?
Vielleicht hast Du ja noch eine Idee, auf jeden Fall schonmal danke für den o.g. Tipp. Nach jetzigem Stand werde ich wohl einfach ein neues Backup auf der neuen Platte anlegen und das alte noch eine Weile auf der alten Platte behalten.
Ich hatte folgende Situation:
- Quelllaufwerk: Externes Laufwerk mit altem TM-Backup. Leider Case-sensitive formatiert. Die auf diesem Laufwerk gesicherten Daten stammen alle von der internen Macintosh HD, welche Journaled, d.h. also case-insensitive, formatiert ist (und immer war). Die oben genannte Bedingung, dass "diese Funktion [case-sensitive] in keinem einzigen der vielen von TM gesicherten Ordner jemals tatsächlich zur Verwendung kam", ist also eigentlich gegeben.
- Ziellaufwerk: Neues Laufwerk für neues TM-Backup. Möchte es nicht mehr case-sensitive haben, daher case-insensitive formatiert.
Das funktioniert im vorliegenden Fall leider nicht. ditto meldet beim Kopieren jedes symlinks innerhalb der Backups.backupdb "Operation not supported".
Ich hatte Deinen Text so verstanden, dass eine "Migration 'zurück' zu einem normalen Volume" (das heisst: Kopie der Backups.backupdb von einem case-sensitive zu einem case-insensitive Laufwerk) mit ditto möglich sein sollte, wenn - klar - die bisher gebackuppte Platte nie case-sensitive war?
Vielleicht hast Du ja noch eine Idee, auf jeden Fall schonmal danke für den o.g. Tipp. Nach jetzigem Stand werde ich wohl einfach ein neues Backup auf der neuen Platte anlegen und das alte noch eine Weile auf der alten Platte behalten.
Die Fehlermeldungen auf Symlinks sind nicht besorgniserregend und verursachen keinen Datenverlust. Sie rühren vom Versuch her, auf diese einen ACL-Eintrag mit Sperrwirkung zu kopieren, den es nicht zwingend braucht. Der scheint nur zu existieren, um die Abwärtskompatibilität eines TM-Volumes zu maximieren, d.h. um dessen Veränderung durch ein Tiger- oder Leopard-System so effektiv wie möglich zu verhindern. Bei einem späteren Restore von Daten aus dem TM-Volume heraus würden diese ohnehin ignoriert.
(Gemeint ist das "everyone: deny delete...", das durchgängig auf alle Objekte in TM-Sicherungen gesetzt wird. Durch das hinzufügen der ditto-Option '--noacl' würde sich das komplett unterdrücken lassen, aber dann würden auch die sinnvolleren ACL-Einträge auf alle anderen Objekte nicht mehr mitkopiert, das wäre dann doch nicht so fabulös.)
(Gemeint ist das "everyone: deny delete...", das durchgängig auf alle Objekte in TM-Sicherungen gesetzt wird. Durch das hinzufügen der ditto-Option '--noacl' würde sich das komplett unterdrücken lassen, aber dann würden auch die sinnvolleren ACL-Einträge auf alle anderen Objekte nicht mehr mitkopiert, das wäre dann doch nicht so fabulös.)
Vielen Dank für die kompetente Antwort. In der Tat konnte ich jetzt vom case-sensitive zum case-insensitive Laufwerk mein Backup kopieren - das ist schonmal ziemlich gut, da fast alle Quellen ansonsten sagen, das sei nicht möglich!
Leider habe ich jetzt ein neues Problem. TimeMachine (der Star-Wars-View) zeigt die alten Backups nicht mehr an. Das erste angezeigte Backup ist das neu erstellte, die älteren Backups werden nicht gezeigt. Ich weiss nicht wirklich, woran es liegt. Bereits als ich TM nach dem Kopieren mittels ditto (und natürlich danach Umbenennen von Backups.temp in Backups.backupdb) wieder startete, wurden die alten Backups nicht erkannt (also noch vor dem Erstellen des aktuellen Backups).
Eine Sache, die mir auffällt, ist, dass die neuen Sicherungen (Dateinamen "2013-02-10-135041" etc.) alle Extended attributes haben, ich also mit xattr -l mir z.B. "com.apple.backup.SnapshotNumber: 1" anzeigen lassen kann (SnapshoptNumber 1 ist das neu erstellte Backup). Die alten Backups (Dateinamen "2012-09-23-173822") haben komischerweise gar keine extended attributes, obwohl die Originaldateien auf der alten Festplatte sehr wohl diese extended attributes hatten, ich sehe sie dort noch. Kann das die Ursache des Problems sein? Laut man-page sollten ditto und mv eigentlich die extended attributes behalten (ich habe keine speziellen anderslautenden Parameter angegeben). Ich kann nur spekulieren, ob TimeMachine die alten Sicherungen nicht als solche erkannt/akzeptiert hat und vielleicht deswegen die extended attributes rausgenommen hat.
Ich könnte natürlich die alten extended attributes einfach rüberkopieren, aber die haben snapshot number 3575 und das scheint mir nicht so richtig viel Sinn zu machen, die vor snapshot number 1 zu kopieren...
Tja, jeder Hinweis ist willkommen, wie ich die alten Backups TimeMachine wieder "bekannt machen" kann...
2003-2024 Apfeltalk | Made on a Mac