Forum

Problem med flytting av Time Machine-sikkerhetskopi til ny ekstern stasjon

D

DevyV

Original plakat
8. august 2020
  • 8. august 2020
hei!

Jeg jobber på macOS Mojave 10.14.6 med siste sikkerhetsoppdatering 2020-004.

Jeg følger denne artikkelen av Apple for å flytte Time Machine-sikkerhetskopien min til en ny USB-disk:
https://support.apple.com/en-us/HT202380

Min gamle Time Machine-sikkerhetskopi er på en 500 GB ekstern HDD kalt 'macOS Time Machine':

Vis medieelementet ' data-single-image='1'>

Som du ser ovenfor, brukes 296,32 GB på denne stasjonen.

Her er det viktig å vite at i tillegg til Time Machine-sikkerhetskopien ('Backups.backupdb'-mappen) har jeg 2 andre mapper på stasjonen som tar opp 73,87 - 69,0 = 142,93 GB plass:

Vis medieelementet ' data-single-image='1'>

Så 296,32 - 73,87 - 69,06 GB = 152,49 GB er størrelsen på Time Machine backup ('Backups.backupdb'-mappen).

Så langt har jeg laget en ny 665,92 GB partisjon på den nye eksterne harddisken:

Vis medieelementet ' data-single-image='1'>

Dra+slipp deretter mappen 'Backups.backupdb' til den nye stasjonens nye partisjon.

Etter en natt med kopiering ser jeg nå dette:

Vis medieelementet ' data-single-image='1'>

Kopivinduet viser meg at macOS kopierte 414,5 GB til den nye stasjonen allerede, men Diskverktøy viser kun brukt plass 344,58 GB . Hvordan kan det ha seg? (ja, jeg har oppdatert Diskverktøy-vinduet)

På det første skjermbildet ovenfor ser jeg at Drive Utility rapporterer at 296,32 GB er brukt på den gamle stasjonen, så hvordan kunne macOS ha kopiert allerede 414,5 GB (og kopierer fortsatt) selv med tanke på at vi vet at jeg har 2 andre mapper på kildestasjonen som jeg ikke kopierer over, så som vi beregnet: Time Machine-mappen må være 152,49 GB bare det som skal kopieres?

Å se på partisjonsinformasjonen er også ganske interessant:


Vis medieelementet ' data-single-image='1'>

Kildepartisjonen (venstre side) har 3.163.830 filer mens målet (høyre side) har 7.208.732 filer og vokser!

Hvordan kunne dette skje? Hvor kommer de 4 millioner filene til fra?!

Dessuten ser kopivinduene ganske rart ut og viser 'Kopier 0 varer til ...' og ikke kunne beregne størrelsen på dataene som skal kopieres: '414,50 GB av 414,5 GB'-tallene fortsetter å vokse parallelt og 'Omtrent 5 sekunder' blir værende for alltid '5 sekunder '.


Hva er galt med denne enkle kopieringsprosessen?
Hvordan kan macOS rapportere så falske tall for en enkel mappekopioperasjon?
Hvordan kan Drive Utility rapportere dårlige tall?

Takk for all hjelp på forhånd!
DevyV C

chabig

6. september 2002


  • 8. august 2020
Jeg ser at stasjonene dine begge er formatert skiller mellom store og små bokstaver. Det er uvanlig. I stedet for å vise oss vinduer fra Diskverktøy, kan du vise oss hva du ser i Finder? Du skal bare se Backups.backupdb.

Jeg mistenker at du har kopiert Backups.backupdb til den nye stasjonen, og deretter satt opp Time Machine på nytt slik at den lager en ny kopi. D

DevyV

Original plakat
8. august 2020
  • 8. august 2020
Takk chabig for at du så på problemet mitt!

Så vidt jeg husker ble kilden Time Machine-partisjonen laget av Time Machine selv da jeg kjørte den for aller første gang, og alt den spurte meg om jeg ønsket å kryptere volumet eller ikke - der jeg valgte 'krypter'. Så jeg valgte ikke alternativet som skiller mellom store og små bokstaver.

I mange guider leste jeg for å lage et 'Journaled' filsystem og egentlig ingen steder jeg leste om alternativet 'case-sensitive' - ​​men nå er det allerede gjort på kildestasjonen.

Da jeg opprettet målpartisjonen, valgte jeg først å skille mellom store og små bokstaver, men da jeg startet kopieringsprosessen, gjorde ikke macOS kopien og ba meg formatere partisjonen til store og små bokstaver, noe jeg gjorde med Diskverktøy.

Det er derfor jeg har skiller mellom store og små bokstaver.

På den annen side har jeg nettopp begynt å kopiere Backups.backupdb til den nye partisjonen - jeg gjorde ingenting annet, enda mer fordi kopieringen fortsatt ikke er fullført og jeg kom ikke til poenget med å endre Time Machine-destinasjonsdisken i innstillingene, så Time Machine er fortsatt satt til å bruke den gamle (kilde)stasjonen (og jeg har aldri hatt automatisk sikkerhetskopiering aktivert, så den bør aldri starte noen sikkerhetskopiering av seg selv):

Vis medieelementet ' data-single-image='1'>

Jeg har nettopp stoppet den uendelige kopieringsprosessen, avmontert og montert den eksterne stasjonen på nytt.

Finder viser kildestasjonen som:

Vis medieelementet ' data-single-image='1'>

og målstasjonen som:

Vis medieelementet ' data-single-image='1'>

Vedlegg

  • Vis medieelement ' href='tmp/attachments/1596892079424-png.941954/' > 1596892079424.png'file-meta'> 89,5 KB · Visninger: 154
  • Se medieelementet ' href='tmp/attachments/1596892142995-png.941955/' > 1596892142995.png'file-meta'> 128,2 KB · Visninger: 132
C

chabig

6. september 2002
  • 8. august 2020
Husk at jeg spekulerer. Målstasjonen viser bare den ene mappen, men den må ha flere filer i den enn originalen. Jeg vet ikke hvorfor.

Det jeg ville gjort er å formatere det nye Time Machine-volumet til Apples foretrukne format, Mac OS Extended (Journaled), og la Time Machine starte på nytt fra bunnen av. Sett den originale Time Machine-stasjonen til side som en eldre sikkerhetskopi, for sikkerhets skyld. Selv om du kanskje tror du mister år med sikkerhetskopier, er alt du egentlig gir opp muligheten til å gå tilbake i tid for eldre versjoner av filer. Hovedverdien til Time Machine er at den beskytter deg hvis primærstasjonen svikter, og din ikke har gjort det. Derfor er det greit å begynne på nytt. D

DevyV

Original plakat
8. august 2020
  • 8. august 2020
Ja. Tross alt er det bare utrolig at macOS ikke kan gjøre en så enkel kopieringsoperasjon Reaksjoner:komatsu D

DevyV

Original plakat
8. august 2020
  • 9. august 2020
For å hjelpe andre, min løsning:

Super duper! kopierte ganske enkelt disse filene over til den nye partisjonen etter sletting, og nå har jeg nøyaktig de samme filene på kilde- og målstasjonene så langt jeg kan måle ved første øyekast.
Selvfølgelig kopierte SD ikke bare Backups.backupdb-mappen, men også de 2 andre mappene som jeg ganske enkelt kan slette nå.
Det tok omtrent 15 timer for min 296,32 GB (fra USB-C til USB-C-disk).

Vis medieelementet ' data-single-image='1'>


Men for ikke å la oss sove godt bare med de nevnte mysteriene, nå når jeg startet MacBook-en min på nytt i dag og bare koblet til New Time Machine-stasjonen, ser det ut som macOS gjenkjente den på en eller annen måte og automatisk satte seg opp til å bruke den som Time Machine-volumet - til tross for alle guider (inkl. Apples ) som sier: ' Etter å ha kopiert den gamle sikkerhetskopifilen til den nye disken, velg den nye disken i Time Machine-innstillingene '

Så det siste mysteriet for de som kom så langt med Apple: merkelig nok er det nye Time Machine-volumet rapportert som
  1. 'Stilling av store og små bokstaver, journalført' (i Finder)
  2. 'Kryptert' (i Time Machine)
  3. 'Kryptert, skiller mellom store og små bokstaver' (i Time Machine)
De to siste er begge innenfor samme applikasjon! En total sammenblanding! Hvilken bør du stemme på nå?
Det ser ut til at macOS kanskje ikke engang vet om seg selv de grunnleggende tingene... bare fortsett å kjøre på en eller annen måte!!! Bra jobbet, Apple!

Vis medieelementet ' data-single-image='1'>


+ sørg for å lese en nyttige råd fra John P

Fantom Gremlin

10. februar 2010
Tualatin, Oregon
  • 22. august 2020
Jeg gikk gjennom dette for noen år siden. Det er et stort problem.

IIRC dette er artikkelen jeg fant det var det jeg endte med å gjøre: https://posts.boy.sh/to-move-your-time-machine-backup-to-another-disk-use-disk-utility

Dette var før 'oppdateringen' ble lagt til den artikkelen. Jeg brukte ikke Finder, jeg brukte Diskverktøy. Fra andre artikler, hvis jeg forstår det riktig, bruker Diskverktøy faktisk Apple Software Restore (asr) for å gjøre det skitne arbeidet.

Det var også med (sannsynligvis) El Capitan og var med HFS+ spinnende stasjoner. Så YMMV med det nyeste operativsystemet, APFS og SSD.

Problemet med ting som SuperDuper er at det ikke vil beholde tidsmaskinhistorien. Jeg tror i hvert fall det, jeg har ikke sjekket det ut.

Jeg kan bekrefte at når jeg gjorde hva det enn var jeg gjorde, ble Time Machine-historien bevart, og det var ingen økning i total plass. På den tiden hadde jeg en 2 TB-stasjon for TM. Det var nesten fullt. Jeg kopierte til en 4 TB-stasjon og endte opp med 2 TB ledig.

Dessuten vet jeg ikke om de 'store og små bokstaver' vil ha noen betydning for denne metoden.
Reaksjoner:Taz Mangus og madrich

Fiskermann

20. februar 2009
  • 27. august 2020
Jeg ville byttet til SuperDuper eller CarbonCopyCloner.
Du har allerede problemer med tm. Hvorfor fortsette å bruke det? P

Fantom Gremlin

10. februar 2010
Tualatin, Oregon
  • 11. september 2020
Fishrrman sa: Du har allerede problemer med tm. Hvorfor fortsette å bruke det?


Tidsmaskin kan gjøre ting som de andre ikke kan.

Time Machine har spesiell tilgang til filsystemprimitiver som lar den utnytte diskplass mer effektivt enn SuperDuper eller CarbonCopyCloner kan. Spesifikt kan IIRC, TM gjøre det unix kaller 'harde lenker' til kataloger, ikke bare til filer. Dette er normalt ikke tillatt (sannsynligvis på grunn av faren for sirkulære lenker).

Disse harde koblingene gjør det mulig å lage raske kopier av hele kataloger, ikke bare filer. Dette gjør det svært tids- og plasseffektivt for TM å vedlikeholde et stort antall gamle øyeblikksbilder.

Jeg er ikke så godt kjent med SuperDuper; Jeg bruker CCC og vet at den tilbyr en historiefunksjon som bevarer flere versjoner av filer. Men uten de spesielle filsystemoperasjonene som er tilgjengelige for TM, kan ikke CCC være på langt nær like effektiv til å gjøre dette.

Fiskermann

20. februar 2009
  • 11. september 2020
Igjen er svaret mitt:
OP prøver å bruke TM og har problemer.
Går han over til CCC eller SD, vil problemene ta slutt.