Hoe je de identiteit van een Time Machine-reservekopie behoudt voordat je een NAS-share hernoemt of opnieuw opbouwt

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Time Machine zal een bestaande NAS-back-upgeschiedenis minder snel verlaten wanneer de back-upidentiteit van de share behouden blijft voordat je die share hernoemt, opnieuw opbouwt of migreert.

Een Time Machine-bestemming op het netwerk is meer dan een map met een sparsebundle. De Mac kan ook afhankelijk zijn van het aangekondigde netwerkvolume, SMB-mogelijkheden, het sharepad, inloggegevens en een volume-identificatie aan de kant van de service. Leg deze identiteitssignalen vast voordat je de NAS wijzigt en bescherm de bestaande sparsebundle. Bouw of hernoem daarna telkens één laag en controleer of de Mac de bedoelde bestemming nog herkent voordat je een nieuwe back-up laat starten.

Leg de huidige netwerkbestemming vast vóór onderhoud

Sla de NAS-hostnaam, het SMB-adres, de sharenaam, het account, de geselecteerde Time Machine-bestemming, de naam van de sparsebundle en de huidige back-upgrootte op. Noteer ook hoe de share wordt gevonden, bijvoorbeeld via een Bonjour-aankondiging of een handmatig gekoppeld SMB-pad.

Apple legt uit dat een netwerkschijf voor Time Machine wordt geselecteerd als netwerkbestemming, en niet zomaar elke map is waarin toevallig back-upbestanden staan.

Maak een NAS-snapshot of een onafhankelijke kopie van de sparsebundle voordat je de sharedefinitie wijzigt. Zo heb je een herstelpunt als de opnieuw opgebouwde service een andere bestemmingsidentiteit aanmaakt of de Mac een nieuwe geschiedenis start.

Behoud de Time Machine-volume-UUID wanneer de NAS dit ondersteunt

Als de NAS een Time Machine-volume-UUID of vergelijkbare persistente identificatie beschikbaar stelt, noteer die dan voordat je de SMB-share verwijdert of opnieuw aanmaakt. Ga er niet van uit dat dezelfde zichtbare sharenaam opnieuw dezelfde identiteit oplevert.

TrueNAS documenteert dat zijn Time Machine-UUID het volume identificeert, en dat het aanmaken of bijwerken van een share met een null-waarde een nieuwe UUID kan genereren.

Herstel de vorige identificatie alleen wanneer de opnieuw opgebouwde share daadwerkelijk dezelfde back-upbestemming vertegenwoordigt en de oude serverinstantie niet meer actief is. Het dupliceren van één UUID op twee actieve bestemmingen zorgt voor nieuwe ambiguïteit.

Houd de SMB-mogelijkheid voor Time Machine ingeschakeld op de opnieuw opgebouwde share

Een gewone SMB-share opnieuw aanmaken op hetzelfde bestandssysteempad is niet voldoende. Controleer of de opnieuw opgebouwde share nog steeds ondersteuning voor Time Machine en de door de Mac verwachte Apple SMB-extensies aankondigt.

De Samba-module vfs_fruit vermeldt dat ondersteuning voor Time Machine wordt aangekondigd via de FULLSYNC-mogelijkheid van de share en, waar ondersteund, via mDNS-registratie.

Vergelijk de oude en nieuwe Samba- of NAS-share-instellingen voordat je de Mac opnieuw verbindt. Als de mogelijkheid is gewijzigd, herstel dan eerst de serverpresentatie in plaats van de sparsebundle te verwijderen of te hernoemen.

-15% OFF
Single board computer zimaboard2

Gebruik een volume-identificatie niet gedachteloos opnieuw

Een behouden netwerkvolume-identificatie is alleen nuttig wanneer die naar dezelfde logische back-upbestemming verwijst. Als je de oude share naar een tweede actieve NAS kloont, mogen beide servers niet doen alsof ze exact hetzelfde Time Machine-volume zijn.

Netatalk waarschuwt dat zijn volume-UUID voor betrouwbare ondubbelzinnige identificatie zorgt en niet gedachteloos moet worden bewerkt of naar een andere server gekopieerd.

Houd tijdens de migratie telkens slechts één bestemming leidend. Breng de vervanging pas online met de behouden identiteit nadat de vorige service offline is en het kopiëren van de sparsebundle is voltooid.

Behoud Bonjour en de shareselectie tijdens de omschakeling

Leg vast welke gedeelde map expliciet voor Time Machine is aangewezen en of Bonjour die map aankondigt. Controleer na het opnieuw opbouwen van de NAS of dezelfde map wordt gepubliceerd voordat je die opnieuw op de Mac selecteert.

De actuele richtlijnen van Synology vereisen dat beheerders de Time Machine-map instellen en Bonjour Time Machine-uitzendingen inschakelen wanneer die detectiemethode wordt gebruikt.

Als de NAS-hostnaam moet veranderen, controleer dan eerst of de bedoelde share via het nieuwe SMB-pad bereikbaar is en nog steeds de beschermde sparsebundle bevat. Laat een lege vervangende share niet de eerste bestemming worden die de Mac ziet.

Test de bestaande geschiedenis voordat je automatische back-ups hervat

Pauzeer automatische back-ups, maak opnieuw verbinding met de opnieuw opgebouwde bestemming, controleer of de oude sparsebundle zichtbaar is en blader naar één bekend bestand uit de vorige geschiedenis of herstel dat bestand. Houd de share in de gaten om te zien of er tijdens de eerste gecontroleerde back-up een tweede sparsebundle wordt aangemaakt.

ASUSTOR raadt SMB aan voor Time Machine-back-ups op ondersteunde NAS-systemen. Dit bevestigt dat de Time Machine-specifieke SMB-presentatie van de server deel uitmaakt van de bestemming.

Het onderhoud is voltooid wanneer Time Machine de bestaande geschiedenis aanvult en er geen tweede bundel verschijnt. Het gerelateerde ZimaSpace-artikel over een nieuwe Time Machine-sparsebundle beschrijft de herstelroute als de identiteit niet is behouden en de Mac al een nieuwe back-up is gestart.

Veelgestelde vragen

Is het genoeg om dezelfde SMB-sharenaam te behouden?

Dat is niet voldoende. De zichtbare naam is slechts één signaal. De NAS kan de share opnieuw aanmaken met andere Time Machine-mogelijkheden, serviceaankondigingen, inloggegevens of een andere volume-identiteit.

Moet ik de bestaande sparsebundle hernoemen zodat die overeenkomt met de opnieuw opgebouwde NAS?

Niet als preventieve sneloplossing. Behoud eerst de bundel en houd de bestemmingsidentiteit stabiel; door de image te hernoemen worden de relaties die Time Machine gebruikt niet automatisch bijgewerkt.

Kan ik de opnieuw opgebouwde share testen terwijl de oude Time Machine-server nog actief is?

Wees voorzichtig. Twee actieve bestemmingen die dezelfde logische identiteit presenteren, kunnen de detectie verwarren en onduidelijk maken welke sparsebundle wordt bijgewerkt. Kies bij voorkeur voor een gecontroleerde omschakeling met één leidende server.

Ondersteuning & Tips

Meer om te lezen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.