Um schreiben oder kommentieren zu können, benötigst du ein Benutzerkonto.
Du hast schon ein Benutzerkonto? Melde dich hier hier an.
Jetzt anmeldenHier kannst du ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellen
Aktuell kann ich kein TM-Backup machen:
Bis zu einem Mainboard-Tausch hat alles funktioniert. Ich habe auch schon mehrfach die Platte formatiert und das Backup neu angelegt. Netzwerklaufwerke etc. sind auch aus dem Backup ausgeschlossen.
Bei dem Backup-Volumen handelt es sich um eine 4TB Partition auf einem Raid0 Verbund aus 2x4TB=8TB.
Hat da jemand eine Idee? Bei einem "nativen" Mac ist mir das noch nicht passiert.
Hast Du schon versucht, das RAID aufzulösen und dann neu zu erstellen? Reden wir von einem Software-RAID unter macOS?
backup auf raid0? das halte ich für keine gute idee...
wieso nicht eine platte als backup, die andere für daten? schon klar, dass raid0 mehr performance bringt, aber damit geht auch die ausfallsicherheit flöten. und das würde ich gerade bei backups nicht haben wollen..
Ist die Festplatte in deiner TimeCapsule APFS formatiert? Soweit ich das in Erinnerung habe, funktioniert nur HFS+ für Backups.
backup auf raid0? das halte ich für keine gute idee...
wieso nicht eine platte als backup, die andere für daten? schon klar, dass raid0 mehr performance bringt, aber damit geht auch die ausfallsicherheit flöten. und das würde ich gerade bei backups nicht haben wollen..
Das ist natürlich alles absolut richtig. Das ist ja nicht mein "Haupt-Backup", sondern mein Paranoia-Wohlfühl-Es-Ist-Auf-Dem-Selben-Rechner-Backup". Ein Time Machine Backup läuft auf ein unraid-NAS im selben Raum, ein weiteres auf ein Synology-NAS im Keller. Fotos und wichtige Daten werden in meine eigene Next-Cloud auf einem root-Server gesynct. Zudem nutze ich für die Fotos die iCloud. Das sollte reichen.
Die beiden Platten als Raid0 hat reine Performance-Gründe. Die Risiken sind mir klar.
Ist die Festplatte in deiner TimeCapsule APFS formatiert? Soweit ich das in Erinnerung habe, funktioniert nur HFS+ für Backups.
Eigentlich nicht. Das ist/war ein "Mac OS Extended (journaled)" Volume. Ich habe es jetzt nochmals alles neu angelegt und das Backup läuft... mal gucken, ob es jetzt funktioniert.
EDIT: Hat nicht funktioniert. Er meckert immer noch beim Fertigstellen des Backups, dass nicht genug Platz wäre obwohl noch 3,2TB frei sind... Grmpf.
Welche von den Diskdevices /dev/diskx ist dein RAID?
Ich sehe hier zwei Raids a 2TB DISKs.
Diese hast du zu einem Raid 0/1 zusammengeschlossen?
Ich sehe zwei Virtuelle Platten / Virtuelle Partitionen:
Welcher davon ist dein Raid?
Gib mal im Terminal ein:
diskutil appleraid list
sollte dann so ausschauen:
Wie du hier sehen kannst habe ich auch 2*4TB als Raid 1.
Ich denke an deiner Konfiguration stimmt etwas nicht.
Wenn du magst schau ich mir das mal per Teamviewer an.
*Ironie mit "einem Schuß Technik" an*...
Vielleicht ist TM so schlau, daß es das Risiko eines RAID-1 erkennt und Dich deshalb verwirren will, damit Du das anders machst? 
Ich verstehe deinen Grundgedanken völlig, ich habe eine Platte "Fast-Backup" auf einer NVME, damit ich ruckzuck meine Experimente korrigen kann.
Die "echten" Backups liegen auf einer HDD (langsam, aber sicher). Wie wäre es denn für Dich mit einer NVME (oder min. SSD) für die "schnellen" Backups?
*Ironie aus*
g-force Beide M.2 Plätze sind besetzt (MacOS und Win10). Eine große Daten-SSD ist auch nich drin. Die Platten hatte ich hier und die finde ich auch für diesen Anwendungsfall perfekt. Natürlich könnte ich die ja auch ohne Raid nutzen... ...aber es lief ja mal, das wurmt mich. Ich rupfe das Raid gleich mal auseinander und teste das mal. Aber ich wette, dass das auch fehl schlägt. Der Fehler liegt IMHO wg. dem Mobo-Tausch in der Time Machine Software und nicht an dem Volume-Setup.
EDIT 1: So, jetzt habe ich die beiden 4TB-Platten einzeln drin und mache ein Backup auf eine der beiden. Mal gucken... dauert halt nun jetzt doppelt so lange 
Und ich wette, dass das auch nicht funktioniert...
EDIT 2: Freunde der Nacht. wie vermutet funktioniert das Backup auch ohne Raid nicht:
Das hat was mit dem Board-Tausch zu tun. Da ist irgendetwas intern verkrumpelt.
Lösch doch mal die com.apple.TimeMachine.plist aus /Library/Preferences raus und probier’s dann nach nem Neustart nochmal.
Nun schon die Fehlermeldung an sich hört sich doch nach einem TM Bug an. Wenn er wirklich nur 1,3 GB braucht aber 3,xx GB frei zu wenig sind stimmt doch was mit der TM selbst nicht und weniger mit der Platte.
Zuletzt hast du die ja einzeln, ohne Raid angeschlossen.
Die Frage ist nun warum sich TM bei der Berechnung was es braucht verrechnet (evtl. braucht es weit mehr!).
Wenn TM Platte leer ist, macht TM ja ein Vollbackup. Wieviel GB soll (was hats du an Quellen HD GB ein/ausgeschlossen) braucht denn dein Vollbackup? Kann ja nur weniger sein wie dein belegter Plattenplatz (abzüglich evtl. Ausschlüsse).
PS: Was zeigt denn geschätzte Größe Backup bei Optionen im Bereich Folgende Objekte nicht sichern an?
Stimmt dort die Größe mit den 1,19 GB überein oder kommt da eine deutlich andere Größe?
Leute die Diskdrill einsetzen (von Cleverfiles) haben z:b. Probleme bei Catalina + TM da DD mit Hardlinks arbeitet (für deren eigene Option DataRecovery). Dort ist jedoch das Problem dass TM Catalina zwar TM beginnt aber nie beenden kann..also etwas anders.
Ich glaube nicht, dass es an den Namen liegt. Die entsprechende macOS-Partition müsste bei dir dann ja "Hacky - Daten" heißen (siehe Befehl "diskutil list"). Der Mountpoint ist /System/Volumes/Data, das ist richtig (sieht man auch im Festplattendienstprogramm). Da aber dein NAS-Laufwerk nicht /System/Volumes/Data, sondern allenfalls /Volumes/Data als Mountpoint hat, kann Time Machine damit eigentlich eh nicht durcheinander kommen. Das müsste schon ein höchst fahrlässiger Bug sein.
Ich hatte mal ein ähnliches Problem. Lösung war seinerzeit in den Optionen, bestimmte Volumens vom TM Backup auszuschließen, die gemounted waren. Hast du mal gecheckt, ob sich TM *nur* um die gewünschten Daten kümmert?
Moment...
Jetzt wo ich darüber noch mal nachdenke wird das mit der UUID des Mainboards zusammenhängen (nicht die SMUUID sondern die SystemID) wenn man die SystemID über Clover nämlich nicht spoofed dann wird die vom Mainboard an das OS weitergereicht und natürlich ändert sich diese UUID wenn man das Mainboard tauscht dann auch. Irgendwie logisch das es dann unter einem OS das Dinge an der UUID festmacht (TM Backups zum Beispiel) dann ins Schleudern geraten wenn sie auf einmal eine andere UUID serviert bekommen insbesondere dann wenn sich sonst nichts an dem System verändert hat (SMBIOS bleibt ja identisch inkl. der SMUUID).
