Big Sur is inmiddels al een tijdje uit, en na de problemen bij verschillende MacBook Pro modellen waarbij de schermen defect gingen, twijfel ik om de stap naar mijn Apple toestellen te zetten. Gaat dat problemen geven?
Dank.
De update staat op al mijn toestellen, alleen na gelezen te hebben over diverse problemen twijfel ik.

Gaat dat problemen geven?

Niet als je een goede backup maakt van tevoren. Want dan kun je terug mocht het toch niet bevallen.

Dank alvast. Zal backup maken en er mij aan wagen.
Zal wat werk vergen!

Ik vind het oplossen door Apple van problemen die ik hier en op andere fora regelmatig tegenkom veel te lang duren. Er had inmiddels allang een .3 of .4 versie moeten zijn uitgebracht. Het is tot nog toe 'hopen dat alles goed gaat', terwijl het eigenlijk een zekerheid had moeten zijn.
Ook het ontbreken van bijv. SuperDuper voor Big Sur (ik kan natuurlijk ook een andere app gebruiken, maar dat wil ik niet) houdt mij nu tegen om deze upgrade te doen.

Omdat ik recent me daarin heb (moeten) verdiep(t/en): na tests met Paragon Backup, CCC en Superduper kwam ik erachter dat ze allemaal echt terugvallen op Apple's eigen toolset voor het maken van backups.

CCC leek te werken, maar vond ik verworden tot een mollige dikkerd (veel opties die ik helemaal niet nodig heb)

Paragon Backup: super lean, gratis, werkte perfect maar deed onder water eigenlijk iets wat je ook met de hand kunt doen.

Superduper: is me niet gelukt om hiermee werkende backups mee te maken. Noch onder Catalina noch onder Big Sur. Superduper lijkt af te wijken van het standaard process en mogelijk heeft dat vroeger goed gewerkt (was altijd mijn favoriet), maar is vervallen tot categorie onbetrouwbaar.

Speurwerk heeft mij geleerd dat Apple in deze veel te verwijten valt. Verandering is goed, alleen de wijze waarop is nogal bedenkelijk. Zie daarbij overigens de kritiek van vrijwel alle ontwikkelaars van Backup-software in een praktisch unisono geluid.

Uitzondering hierbij is mogelijk de ontwikkelaar van Carbon Copy Cloner, maar ook die heeft het nodige te klagen gehad. Mogelijk heeft hij als (ex Apple ontwikkelaar?) nog steeds iets betere toegang tot Apple.

Het punt is dat de door Apple aangereikte toolset om bootable backups van logische volumes (ASR) niet werkte en alles rondom APFS nogal een bedenkelijk volwassenheidsniveau had.

Maar het is me gelukt om het werkend te krijgen:

Stappen:

- bereid de interne harde schijf voor door deze te ontdoen van allerlei onnodige caches en overige zaken (Onyx kan je hierbij helpen, maar er zijn natuurlijk andere manieren)

- Lokale Time Machine backups zorgen voor veel problemen bij het terugzetten van backups. Je kunt beter een kopie maken (mag via time machine) op een extern volume en de interne backups verwijderen. (let wel: eigen ervaring met wat testen afgelopen dagen waarbij vele pogingen faalden)

- In navolging van hierboven: wis de lokale timemachine backups

open de terminal en geef in:

tmutil listlocalsnapshots /
kijk of je snapshots ziet. krijg je Snapshots for volume group contains disk /: en dan niets, dan heb je geen lokale snapshots en kun je verder. Heb je wel allerlei data teruggekoppeld gekregen:

- Stop de time machine backup (kun je later weer aanzetten)

tmutil stopbackup
- Verwijder alle LOKALE kopieen (snapshots):

tmutil deletelocalsnapshots /
- Maak vervolgens een LEGE disk image aan op de schijf waar je dat wenst:

Voorbeeld

sudo hdiutil create -size 250g -layout GPTSPUD -fs APFS -verbose -type SPARSE -nospotlight -attach /Volumes/Mac\ Data/ASR\ Backup/ASR\ \-\ Backup
In dit voorbeeld:

Mac Data Partitie
ASR Backup Directory
ASR - Backup als diskimage

Je kunt ook aanhalingstekens gebruiken (") en je hebt vervolgens geen last van de "\" back-slashes in unix.

Hierop maakt macOS een lege diskimage aan (in dit geval eentje van 250GB, maar je kunt elke waarde opgeven, van 1GB tot 999GB). macOS maakt in dit geval een SPARSE image aan, hetgeen betekend dat het de ruimte heeft om te groeien tot de door jou ingegeven omvang, maar dit enkel doet als er echt gegevens in worden opgeslagen.

- We openen disk utility om te kijken welke schijf het systeem nu feitelijk op zit. Wat is namelijk het geval: sinds de volledige overgang naar APFS werken we met logische volumes en dat betekend dat schijf een ouderwetse partitie kent (EFI op de eerste paritite en dan Apple_APFS Container). binnen deze partitie hebben we de feitelijke onderverdeling in volumes

(macOS (alleen lezen), macOS - Data, PreBoot, Recovery, VM). Dit zijn volumes en, zoals Apple dat zo mooi noemt: "synthesized volumes").

Kijk onder informatie welk schijf-nummer dit heeft (in mijn voorbeeld disk2)

- Doe hetzelfde voor het doelarchief (de schijfkopie), kijk welk (virtueel) schijfnummer deze heeft. In mijn geval: disk4

- Hierna geven we de feitelijk opdracht om een kopie te maken van het gehele systeem

sudo asr --source /dev/disk2 --target /dev/disk4 --erase --verbose
- Het systeem gaat nu los en maakt de feitelijke kopie. Dit kan even duren.

- Nu gaan we de schijfkopie kleiner maken (comprimeren) en klaarstomen om probleemloos terug te kunnen zetten. Het werkt overigens ook met Sparse Images, maar dit zijn niet beveiligde images waar nog het nodige mee kan gebeuren en ontberen een checksum. Vandaar dat ik eigenlijk standaard de images omzet naar een gecomprimeerd image en vervolgens voorzie van een checksum:

diskutil eject disk4hdiutil convert -format UDZO -o /Volumes/Mac\ Data/ASR\ Backup/ASR\ \-\ Backup.dmg /Volumes/Mac\ Data/ASR\ Backup/ASR\ \-\ Backup.SPARSEIMAGE
- Wederom gaat dit even duren

- Dan nog tot slot eens valideren of alles goed zit

asr imagescan --source /Volumes/Mac\ Data/ASR\ Backup/ASR\ \-\ Backup.dmg
- Weer even wachten totdat er een controlegetal wordt gegenereerd

En ... klaar!

Je hebt een volledig werkende kopie van het systeem op schijf.

Terugzetten?

- Mac Booten in Herstel modus

- Terminal Openen en het volgende ingeven:

hdiutil attach /Volumes/Mac\ Data/ASR\ Backup/ASR\ \-\ Backup.dmg
Het systeem gaat eerst de checksum valideren. Heb je er geen zin in om hierop te wachten:

hdiutil attach -noverify /Volumes/Mac\ Data/ASR\ Backup/ASR\ \-\ Backup.dmg
- nu kijken welk schijfnummer hieraan gekoppeld is (synthesized disk). dit nummer gebruiken we bij het terugzetten van de schijf.

- valideren wat de doelschijf is (schijfnummer). In geval van twijfel: disk utility openen en middels grafische interface kijken en wederom info opvragen en dan weer naar de terminal terugkeren.

- en nu wordt het spannend. Heb je catalina:

(voorbeeld nummers, waarbij disk4 de bronschijf is en disk1 de (interne) doelschijf):

asr restore --source /dev/disk4 --target /dev/disk1
Hierop krijg je iets te zien in de trend van:

Validating target...done
Validating source...done
Erase contents of /dev/disk1 ()? [ny]: y
Replicating ....10....20....30....40....50....60....70....80....90....100
Replicating ....10....20....30....40....50....60....70....80....90....100
Restored target device is /dev/disk1s2.
Restore completed successfully.
Mocht dit onverhoopt falen, om welke reden dan ook. Dan kun je macOS ook de opdracht geven om op een andere manier de zaken terug te zetten:

asr restore --source /dev/disk4 --target /dev/disk1 --useInverter

Validating target...done
Validating source...done
Validating sizes...done
Restoring  ....10....20....30....40....50....60....70....80....90....100
Verifying  ....10....20....30....40....50....60....70....80....90....100
Inverting target volume...done
Restoring  ....10....20....30....40....50....60....70....80....90....100
Verifying  ....10....20....30....40....50....60....70....80....90....100
Inverting target volume...done
Restored target device is /dev/disk1s2.
Gegarandeerd succes. Hierna niet vergeten nog je opstartschijf te selecteren, herstarten en klaar ...

Werk je met Big Sur:

sudo asr restore --source /dev/disk4s2 --target /dev/disk1 --erase --sourcevolumename macOS
Validating target...done
Validating source...done
Erase contents of /dev/disk1 ()? [ny]: y
Replicating ....10....20....30....40....50....60....70....80....90....100
Replicating ....10....20....30....40....50....60....70....80....90....100
Restored target device is /dev/disk1s2.
Restore completed successfully.
- Met de kanttekening dat je onder Big Sur nu dus het (oorspronkelijke) volumenaam moet opgeven en (kennelijk) de exacte partitie.

Wat ik hier lastig aan vind is dat er zulke grote wijzigingen plaatsvinden soms zelfs tijdens "incremental" updates. Het lijkt alsof de verschillen niet groot zijn, maar software van derden moet wel weten hoe de macOS backend aan te spreken. Verder heeft het onder de eerste versie van Big Sur niet gewerkt en een lange tijd was de tool defect onder Catalina ...

... dat vind ik bijzonder zwak en een understatement voor het broddelwerk. Backups zijn namelijk een fundamenteel onderdeel van een besturingssysteem.

Onder Catalina werkt het 100% (wel onder 10.15.7), onder Big Sur werkt het ook. Heb alleen hier kunnen testen met 11.0.1. Ik heb al redelijk wat data verbrast op mijn internetlijn, dus om weer gigabytes te gaan downloaden zie ik niet zitten. Ben namelijk niet thuis en werk met een LTE verbinding.

Hoe dan ook: er zijn alternatieven ... voor de hobbyist

- Lokale Time Machine backups zorgen voor veel problemen bij het terugzetten van backups. Je kunt beter een kopie maken (mag via time machine) op een extern volume en de interne backups verwijderen.

Een lokale backup van TM is natuurlijk geen backup. Als die schijf defect is, heb je helemaal niets. Dus nooit lokaal backuppen!

Overigens een 👌 voor je doorzettingsvermogen om dit allemaal werkend te krijgen. Veel te complex voor mij, dus ik blijf nog bij Catalina...

.

Paragon Backup: super lean, gratis, werkte perfect maar deed onder water eigenlijk iets wat je ook met de hand kunt doen.

Dat 'met de hand' ziet er gelukkig heel simpel uit. 

Ben wel benieuwd naar dat Paragon Backup. Overigens nog niet geschikt voor Big Sur.

Weet je of PB ook incremental backups maakt?

“Backups zijn namelijk een fundamenteel onderdeel van een besturingssysteem.”

Dat is natuurlijk dikke onzin. Backups maken behoort een onderdeel te zijn van je eigen werkroutine om je data veilig te stellen niet dat van een OS.

Jawel, maar dan moet dat wel werken. En het is meermaals in afgelopen macOS versies gebleken dat een volwaardige (bootable) diskimage maken helemaal niet mogelijk was omdat er verschillende zaken in het systeem niet naar behoren werkten of (soms zonder zelfs enige vooraankondiging) (wederom) veranderdt waren.

Dus dat je als gebruiker een eigen verantwoordelijkheid hebt: ja, dat klopt.

Maar dan moet het wel allemaal werken en er een mogelijkheid zijn om een backup te maken.

Timemachine is niet voor iedereen toerijkend en ... is ook geregeld gebleken dat Time Machine ook niet feilloos was. Dus een backup strategie met meerdere opslagmethoden lijkt me voor de hand te liggen.

Opnieuw installeren en dan data terugzetten kan leuk klinken, maar hier even een reality check (en ik heb echt niet dramatisch veel geinstalleerd): 98GB aan software en libraries. Hier zit nog niet de USERDATA bij. Daar heb ik echt helemaal 0,0 zin in om dat elke keer weer opnieuw te downloaden en te installeren.

Zoals gezegd, eens met de stelling: eigen verantwoordeijkheid. Maar zoals aangegeven: backups zijn een fundamenteel onderdeel van een operatingsysteem. Oftewel: er moet een mogelijkheid bestaan om backups te maken -- daar ging het me meer om.

Groet!

Dat 'met de hand' ziet er gelukkig heel simpel uit. 

Ben wel benieuwd naar dat Paragon Backup. Overigens nog niet geschikt voor Big Sur.

Weet je of PB ook incremental backups maakt?

Nee, enkel full disk images.

@ doctor_apple ; Als ik je verhaal zo lees is het vooralsnog schluß met SuperDuper! en is CCC nu de enige app die werkt (met incremental backups).

“Backups zijn namelijk een fundamenteel onderdeel van een besturingssysteem.”

Dat is natuurlijk dikke onzin. Backups maken behoort een onderdeel te zijn van je eigen werkroutine om je data veilig te stellen niet dat van een OS.

Kom op zeg. Het hebben van betrouwbare backups is een basisvoorwaarde van het digitale leven. Een OS maker hoort dat niet over te laten aan derde partijen, maar moet zorgen voor goede ondersteuning hierin. Net zoals een hoge mate van veiligheid ook een zaak van de OS maker is. Allerlei andere toetertjes en belletjes, die mogen ze overlaten aan app-bouwers.
Apple heeft dat goed opgepakt met TM, maar het lijkt erop dat ze hun focus op TM aan het verliezen zijn. En daar kan ik pislink om worden.

Wat je ook doet: als je een printer gebruikt: die gaat niet meer op normale wijze werken.

De titel van dit draadje is aangepast (was “Big Sur”), zodat het duidelijker is waar het om gaat en het ook beter vindbaar is.

.

Niet mee eens. Dan kun je de lijn wel verder trekken ook, dan moet een OS ook voorzien in tekstverwerking, fotobewerking, webdesign, etc. Zou een strop zijn voor 3rd party softwarehuizen. Daarbij is er voor veel mensen geen noodzaak tot backup. Enerzijds omdat er niets te backuppen valt en anderzijds omdat belangrijke data al centraal staat en de computer niets meer dan een terminal is. Voor de mensen die wel willen backuppen is er dan 3rd party software of je doet het met de hand. Dat in dit geval bepaalde backupsoftware niet werkt is te wijten aan de softwarehuizen die het spul maken.

Hier ben ik het nou echt totaal niet mee eens. Een goede backupstrategie is echt absoluut noodzakelijk, en goede ingebouwde backupfaciliteiten een onmisbaar onderdeel van ieder OS. Je moet het mensen op dit gebied zo makkelijk mogelijk maken (want anders maken velen geen backup), en Apple heeft dit met TM in principe ook gedaan; en als Apple nu steken laat vallen op dit gebied, dan is dat betreurenswaardig.

Naast TM ook een ander backup-programma gebruiken, om niet alleen van de TM-kopie afhankelijk te zijn, is natuurlijk zeer verstandig, maar dat moet iedereen zelf weten. Tekst- en fotoprogramma's zijn van een heel andere orde. Apple hoeft niet iedereen standaard een leunstoel aan te bieden, maar moet wel zorgen dat het dak niet lekt en dat de vloer niet spiegelglad is.

En wat cloud-backups betreft: hoeveel mensen zijn er niet die daarvan in de war raken? Die niet meer weten wat waar precies staat, en hier komen klagen dat er dingen verdwenen zijn? Nee, een TM-backup op een externe harde schijf is echt noodzakelijk, en Apple dient goede programmatuur daarvoor in het OS te (blijven) verwerken.

Wat je ook doet: als je een printer gebruikt: die gaat niet meer op normale wijze werken.

Geen last van gehad hier in huis.

Omdat ik recent me daarin heb (moeten) verdiep(t/en): na tests met Paragon Backup, CCC en Superduper kwam ik erachter dat ze allemaal echt terugvallen op Apple's eigen toolset voor het maken van backups.

CCC leek te werken, maar vond ik verworden tot een mollige dikkerd (veel opties die ik helemaal niet nodig heb)

Paragon Backup: super lean, gratis, werkte perfect maar deed onder water eigenlijk iets wat je ook met de hand kunt doen.

Superduper: is me niet gelukt om hiermee werkende backups mee te maken. Noch onder Catalina noch onder Big Sur. Superduper lijkt af te wijken van het standaard process en mogelijk heeft dat vroeger goed gewerkt (was altijd mijn favoriet), maar is vervallen tot categorie onbetrouwbaar.

Speurwerk heeft mij geleerd dat Apple in deze veel te verwijten valt. Verandering is goed, alleen de wijze waarop is nogal bedenkelijk. Zie daarbij overigens de kritiek van vrijwel alle ontwikkelaars van Backup-software in een praktisch unisono geluid.

Uitzondering hierbij is mogelijk de ontwikkelaar van Carbon Copy Cloner, maar ook die heeft het nodige te klagen gehad. Mogelijk heeft hij als (ex Apple ontwikkelaar?) nog steeds iets betere toegang tot Apple.

Het punt is dat de door Apple aangereikte toolset om bootable backups van logische volumes (ASR) niet werkte en alles rondom APFS nogal een bedenkelijk volwassenheidsniveau had.

Maar het is me gelukt om het werkend te krijgen:

Stappen:

- bereid de interne harde schijf voor door deze te ontdoen van allerlei onnodige caches en overige zaken (Onyx kan je hierbij helpen, maar er zijn natuurlijk andere manieren)

- Lokale Time Machine backups zorgen voor veel problemen bij het terugzetten van backups. Je kunt beter een kopie maken (mag via time machine) op een extern volume en de interne backups verwijderen. (let wel: eigen ervaring met wat testen afgelopen dagen waarbij vele pogingen faalden)

- In navolging van hierboven: wis de lokale timemachine backups

open de terminal en geef in:

Code: [Selecteer]

tmutil listlocalsnapshots /
kijk of je snapshots ziet. krijg je Snapshots for volume group contains disk /: en dan niets, dan heb je geen lokale snapshots en kun je verder. Heb je wel allerlei data teruggekoppeld gekregen:

- Stop de time machine backup (kun je later weer aanzetten)

Code: [Selecteer]

tmutil stopbackup
- Verwijder alle LOKALE kopieen (snapshots):

Code: [Selecteer]

tmutil deletelocalsnapshots /
- Maak vervolgens een LEGE disk image aan op de schijf waar je dat wenst:

Voorbeeld

Code: [Selecteer]

sudo hdiutil create -size 250g -layout GPTSPUD -fs APFS -verbose -type SPARSE -nospotlight -attach /Volumes/Mac\ Data/ASR\ Backup/ASR\ \-\ Backup
In dit voorbeeld:

Mac Data Partitie
ASR Backup Directory
ASR - Backup als diskimage

Je kunt ook aanhalingstekens gebruiken (") en je hebt vervolgens geen last van de "\" back-slashes in unix.

Hierop maakt macOS een lege diskimage aan (in dit geval eentje van 250GB, maar je kunt elke waarde opgeven, van 1GB tot 999GB). macOS maakt in dit geval een SPARSE image aan, hetgeen betekend dat het de ruimte heeft om te groeien tot de door jou ingegeven omvang, maar dit enkel doet als er echt gegevens in worden opgeslagen.

- We openen disk utility om te kijken welke schijf het systeem nu feitelijk op zit. Wat is namelijk het geval: sinds de volledige overgang naar APFS werken we met logische volumes en dat betekend dat schijf een ouderwetse partitie kent (EFI op de eerste paritite en dan Apple_APFS Container). binnen deze partitie hebben we de feitelijke onderverdeling in volumes

(macOS (alleen lezen), macOS - Data, PreBoot, Recovery, VM). Dit zijn volumes en, zoals Apple dat zo mooi noemt: "synthesized volumes").

Kijk onder informatie welk schijf-nummer dit heeft (in mijn voorbeeld disk2)

- Doe hetzelfde voor het doelarchief (de schijfkopie), kijk welk (virtueel) schijfnummer deze heeft. In mijn geval: disk4

- Hierna geven we de feitelijk opdracht om een kopie te maken van het gehele systeem

Code: [Selecteer]

sudo asr --source /dev/disk2 --target /dev/disk4 --erase --verbose
- Het systeem gaat nu los en maakt de feitelijke kopie. Dit kan even duren.

- Nu gaan we de schijfkopie kleiner maken (comprimeren) en klaarstomen om probleemloos terug te kunnen zetten. Het werkt overigens ook met Sparse Images, maar dit zijn niet beveiligde images waar nog het nodige mee kan gebeuren en ontberen een checksum. Vandaar dat ik eigenlijk standaard de images omzet naar een gecomprimeerd image en vervolgens voorzie van een checksum:

Code: [Selecteer]

diskutil eject disk4

Code: [Selecteer]

hdiutil convert -format UDZO -o /Volumes/Mac\ Data/ASR\ Backup/ASR\ \-\ Backup.dmg /Volumes/Mac\ Data/ASR\ Backup/ASR\ \-\ Backup.SPARSEIMAGE
- Wederom gaat dit even duren

- Dan nog tot slot eens valideren of alles goed zit

Code: [Selecteer]

asr imagescan --source /Volumes/Mac\ Data/ASR\ Backup/ASR\ \-\ Backup.dmg
- Weer even wachten totdat er een controlegetal wordt gegenereerd

En ... klaar!

Je hebt een volledig werkende kopie van het systeem op schijf.

Terugzetten?

- Mac Booten in Herstel modus

- Terminal Openen en het volgende ingeven:

Code: [Selecteer]

hdiutil attach /Volumes/Mac\ Data/ASR\ Backup/ASR\ \-\ Backup.dmg
Het systeem gaat eerst de checksum valideren. Heb je er geen zin in om hierop te wachten:

Code: [Selecteer]

hdiutil attach -noverify /Volumes/Mac\ Data/ASR\ Backup/ASR\ \-\ Backup.dmg
- nu kijken welk schijfnummer hieraan gekoppeld is (synthesized disk). dit nummer gebruiken we bij het terugzetten van de schijf.

- valideren wat de doelschijf is (schijfnummer). In geval van twijfel: disk utility openen en middels grafische interface kijken en wederom info opvragen en dan weer naar de terminal terugkeren.

- en nu wordt het spannend. Heb je catalina:

(voorbeeld nummers, waarbij disk4 de bronschijf is en disk1 de (interne) doelschijf):

Code: [Selecteer]

asr restore --source /dev/disk4 --target /dev/disk1
Hierop krijg je iets te zien in de trend van:

Code: [Selecteer]

Validating target...done
Validating source...done
Erase contents of /dev/disk1 ()? [ny]: y
Replicating ....10....20....30....40....50....60....70....80....90....100
Replicating ....10....20....30....40....50....60....70....80....90....100
Restored target device is /dev/disk1s2.
Restore completed successfully.
Mocht dit onverhoopt falen, om welke reden dan ook. Dan kun je macOS ook de opdracht geven om op een andere manier de zaken terug te zetten:

Code: [Selecteer]

asr restore --source /dev/disk4 --target /dev/disk1 --useInverter

Validating target...done
Validating source...done
Validating sizes...done
Restoring  ....10....20....30....40....50....60....70....80....90....100
Verifying  ....10....20....30....40....50....60....70....80....90....100
Inverting target volume...done
Restoring  ....10....20....30....40....50....60....70....80....90....100
Verifying  ....10....20....30....40....50....60....70....80....90....100
Inverting target volume...done
Restored target device is /dev/disk1s2.
Gegarandeerd succes. Hierna niet vergeten nog je opstartschijf te selecteren, herstarten en klaar ...

Werk je met Big Sur:

Code: [Selecteer]

sudo asr restore --source /dev/disk4s2 --target /dev/disk1 --erase --sourcevolumename macOS
Validating target...done
Validating source...done
Erase contents of /dev/disk1 ()? [ny]: y
Replicating ....10....20....30....40....50....60....70....80....90....100
Replicating ....10....20....30....40....50....60....70....80....90....100
Restored target device is /dev/disk1s2.
Restore completed successfully.
- Met de kanttekening dat je onder Big Sur nu dus het (oorspronkelijke) volumenaam moet opgeven en (kennelijk) de exacte partitie.

Wat ik hier lastig aan vind is dat er zulke grote wijzigingen plaatsvinden soms zelfs tijdens "incremental" updates. Het lijkt alsof de verschillen niet groot zijn, maar software van derden moet wel weten hoe de macOS backend aan te spreken. Verder heeft het onder de eerste versie van Big Sur niet gewerkt en een lange tijd was de tool defect onder Catalina ...

... dat vind ik bijzonder zwak en een understatement voor het broddelwerk. Backups zijn namelijk een fundamenteel onderdeel van een besturingssysteem.

Onder Catalina werkt het 100% (wel onder 10.15.7), onder Big Sur werkt het ook. Heb alleen hier kunnen testen met 11.0.1. Ik heb al redelijk wat data verbrast op mijn internetlijn, dus om weer gigabytes te gaan downloaden zie ik niet zitten. Ben namelijk niet thuis en werk met een LTE verbinding.

Hoe dan ook: er zijn alternatieven ... voor de hobbyist

Ahem, doctor_apple, jij lijkt me heel wat meer dan een hobbyist en erg bedreven in Unix Terminal ( BASH of andere zoals ZSHELL of OhMyZshell)) daarenboven!

Ik, als gewone sterveling, betreur het dat er voor voor de gewone gebruiker geen valabele brug wordt geboden
tussen TM backups van voor, en van na Big Sur.
En dat oude getrouwen zoals SuperDuper en CCC niet meer naar behoren schijnen te werken onder Big Sur.

Rosetta2 schijnt een mooie voorlopige brug voor apps, maar dus niet voor boven genoemde.

Wat zou je denken van RSync als alternatief voor een bootable backup onder de huidige omstandigheden?
https://rsyncosx.github.io/nextrelease

Big Sur is inmiddels al een tijdje uit, en na de problemen bij verschillende MacBook Pro modellen waarbij de schermen defect gingen, twijfel ik om de stap naar mijn Apple toestellen te zetten. Gaat dat problemen geven?
Dank.

Hardware gaat niet per definitie stuk vanwege een nieuw besturingssysteem. Dat is dus niet afhankelijk van Big Sur of welk ander OS dan ook. En wanneer je het al op al je apparaten hebt staan ben je feitelijk een stap te laat, het leed is al geleden.

Als het gaat om de kwaliteit van de MacBooks en de vraag of je nu over zou moeten naar een MacBook met M1 CPU dan is dat een heel andere afweging. Ook met de M1 modellen lees ik her en der wel issues. Dus ja, als het een productiemachine betreft zou ik nog wachten op een M2, of verder uiteraard. Maar ja, wanneer ga je dan over? Sinds 2008 heeft Apple volgens mij geen foutloze serie meer uitgebracht, er is altijd wel iets met een bepaald model aan de hand.

Ahem, ik start probleemloos een MacBook 2007 met een SSD die ook draait op een mid 2012 MacBook Pro. Onder El Capitan.
Maar deze glorieuze tijden behoren tot het verleden vrees ik...

Mja, de MacBook 2012 had een brakke SATA kabel, weet je nog? De 2007 had last van afbrekend plastic...

Eigenlijk is de Unibody 2008 zo'n beetje het beste model tot nu toe. Daar heb ik tot nu toe nog geen massale klachten over gelezen. (laat ik nou bevoorrecht/bevooroordeld zijn om/door 11 jaar op zo'n MacBook gewerkt te hebben)

Denk dat ik alles zo laat. Alles draait onder Catalina.( Citaat ) als alles goed werkt, laat het dan zo.ben tevreden met het huidig OS.
Is ook veel werk, en wat met mijn beeldbewerking software.
Kan je de notificatie van de update Big Sur verwijderen? Zo ja, hoe.
Ga binnen 8 maanden de nieuwe MacBook Air halen met de M1

Dank allemaal voor de hulp.