„De reservekopieschijfkopie kan niet worden aangemaakt” en fout 45

Waarom er überhaupt een schijfkopie is

Time Machine heeft functies van een bestandssysteem nodig die een netwerkshare niet biedt: harde links, eigenaarschap dat het zelf beheert en de mogelijkheid een bestand te vergrendelen terwijl het ermee bezig is. Een NAS die SMB spreekt, kan dat niet beloven.

Dus op elke netwerkbestemming maakt Time Machine een sparse bundle, een map die eindigt op .sparsebundle en zich gedraagt als schijfkopie. Het koppelt die schijfkopie, en de backup staat erin op een bestandssysteem dat Time Machine volledig beheert. De share hoeft alleen een map met genummerde stukken, bands genoemd, te bewaren.

Daarom heeft een netwerkbackup een hele categorie storingen die een aangesloten schijf niet heeft. Er kunnen twee dingen misgaan waar een aangesloten schijf er één heeft, en de melding die je krijgt gaat meestal over de schijfkopie.

De meldingen, en wat elk betekent

„De reservekopieschijfkopie kan niet worden aangemaakt”

Time Machine probeerde de sparse bundle te maken en de share weigerde. Loop deze stappen op volgorde door.

• De share wordt niet aangeboden voor Time Machine. Een NAS heeft daar een instelling voor, meestal een vinkje bij de gedeelde map. Op een Linux-machine met Samba is het fruit:time machine = yes in de sharedefinitie. Zonder dat kan macOS prima verbinden en toch weigeren de schijfkopie te maken.
• Er is niet genoeg ruimte. De schijfkopie wordt aangemaakt met een vastgelegde maximale grootte. Een share met een quota kleiner dan dat maximum mislukt bij het aanmaken. Controleer de quota van de share, niet de vrije ruimte van de hele pool, want dat is een ander getal.
• Rechten. Het account waarmee je verbond, heeft schrijftoegang nodig tot de hoofdmap van de share zelf. Een map daarin is niet genoeg.
• De naam. De schijfkopie is vernoemd naar je Mac. Een Mac-naam met een schuine streep, dubbele punt of emoji erin heeft precies deze storing veroorzaakt. Wijzig hem in Systeeminstellingen, Algemeen, Info, en probeer het opnieuw.

„De reservekopieschijfkopie is niet toegankelijk (fout 45)”

De schijfkopie bestaat en macOS kon hem niet koppelen. Fout 45 is een vergrendelingsfout, dus de gebruikelijke oorzaak is dat iets de schijfkopie al open heeft.

1. Ontkoppel de share en koppel hem opnieuw. Werp hem uit in de Finder, wacht en verbind opnieuw. Dit lost de meeste op.
2. Kijk of een andere Mac hem open heeft. Twee Macs die naar dezelfde share backuppen, krijgen elk een eigen schijfkopie, en een tweede Mac die de jouwe per ongeluk heeft gekoppeld, houdt de vergrendeling vast. De meeste beheerpagina's van een NAS hebben een lijst met open bestanden of verbonden sessies.
3. Herstart de NAS. Grof, en het verwijdert een vergrendeling van een gecrasht proces op de server, die niets op de Mac kan vrijgeven.
4. Verwijder de verlopen vergrendeling in de bundel. Een sparse bundle is een map. Klik er met de rechtermuisknop op, kies Toon pakketinhoud en zoek bovenaan naar token of een .lock-bestand. Die verwijderen is veilig als niets de schijfkopie heeft gekoppeld, en ze worden bij de volgende koppeling opnieuw gemaakt. Zorg dat de schijfkopie eerst niet gekoppeld is, anders beschadig je hem.

„is al in gebruik” of „in gebruik door een ander apparaat”

Dezelfde oorzaak, duidelijker gezegd, en dezelfde vier stappen lossen het op. Kijk eerst in de navigatiekolom van de Finder of er een volume met de naam van je Mac is gekoppeld, want het meest voorkomende antwoord is dat hij op dit moment gekoppeld is op de machine waar je achter zit.

„Time Machine kan de reservekopie niet voltooien. De reservekopieschijfkopie is niet toegankelijk”

Meestal verdween de share midden in een backup, door slaapstand, wifi of een NAS die herstartte voor een update. Kijk of de share weer verbindt en controleer de schijfkopie dan met de verificatiestap hieronder voordat je vertrouwt op wat erin staat.

Controleer de schijfkopie voordat je hem vertrouwt

Een onderbroken netwerkbackup kan de schijfkopie intern inconsistent achterlaten terwijl elke melding op het scherm er goed uitziet. Koppel hem en vraag het systeem:

hdiutil attach -readonly /Volumes/<share>/<YourMac>.sparsebundle

diskutil verifyVolume /Volumes/<the volume it mounted>

Alleen-lezen, dus kijken verandert niets. Meldt de verificatie fouten, voer dan diskutil repairVolume uit op hetzelfde volume. Mislukt de reparatie, dan is die schijfkopie klaar, en de eerlijke stap is er een nieuwe backupreeks op te beginnen en niet meer te vertrouwen op wat in de oude staat.

Wat dit je kost, gewoon gezegd

Elk van deze fouten is een eigenschap van de schijfkopie, en de schijfkopie bestaat omdat de bestemming op het netwerk staat. Een backup die gewone bestanden in een gewone map schrijft, heeft hier niets van: geen schijfkopie die niet kan worden gemaakt, geen vergrendeling die blijft hangen, geen enkel groot object waarvan beschadiging elke backup erin tegelijk meeneemt.

Dat laatste punt is het waard om bij stil te staan. Je hele Time Machine-geschiedenis op een NAS staat in één sparse bundle. Het is één object. Schade op de verkeerde plek neemt alles mee.

Hoe Copy Shelter met een NAS omgaat

Het schrijft een map met gewone bestanden naar de share, dus er is geen schijfkopie, geen vergrendeling en geen enkel object met elke versie die je hebt. Een share die midden in een backup offline gaat, wordt gemeld als onbereikbare bestemming, met de datum waarop hij voor het laatst is gezien, en de volgende backup gaat verder waar de vorige stopte.

Elk stuk wordt opgeslagen onder de hash van de eigen inhoud en volgens schema tegen die hash teruggelezen, zodat schade waar dan ook in de reeks op een gewone dinsdag wordt benoemd en gevonden. Een backup van een Mac maken naar een NAS behandelt de opzet, inclusief het time-outgedrag dat bepaalt of een slapende share een fout is of gewoon afwezig.

Veelgestelde vragen

Kan ik de sparsebundle verwijderen en opnieuw beginnen?

Dat kan, en het gooit elke backup erin weg, want die staan allemaal in die ene schijfkopie. Probeer eerst de vier stappen hierboven. Verwijderen is pas het antwoord als diskutil repairVolume er al op is mislukt.

Waarom doet mijn USB-schijf dit nooit?

Omdat er geen schijfkopie is. Een direct aangesloten schijf krijgt een eigen bestandssysteem dat Time Machine formatteert en beheert, dus er is geen kopie nodig en geen vergrendeling die kan blijven hangen. Dat is het sterkste argument om één lokale kopie te houden.

De NAS zegt dat hij Time Machine ondersteunt. Waarom mislukt het dan toch?

Het ondersteunen en het aanhebben op die specifieke share zijn bij de meeste NAS-software verschillende instellingen. Controleer de share, niet de productpagina. Quota's zijn de andere veelvoorkomende oorzaak: de schijfkopie legt bij het aanmaken een maximale grootte vast, en een kleinere quota weigert die.

Is fout 45 gevaarlijk?

Op zich niet. Het betekent dat macOS de schijfkopie niet kon vergrendelen, dus er is niets geschreven. Gevaarlijk is een lange reeks ervan die niemand opmerkt, want de laatste goede backup wordt steeds ouder terwijl alles normaal lijkt.

Gebruikt Copy Shelter een schijfkopie op een netwerkshare?

Nee. Het schrijft gewone bestanden in een map op de share, en daarom bestaat geen van de fouten op deze pagina ervoor. De keerzijde is dat de share bereikbaar moet zijn om mee te tellen, en de app zegt het als dat niet zo is.

Gerelateerd: een backup van een Mac maken naar een NAS, Time Machine zegt dat er niet genoeg ruimte is en een backup verifiëren.