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.
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

Kan Plex een GPU delen met een andere Docker-container?
Plex en een andere container kunnen vaak dezelfde GPU gebruiken, maar je moet de driverondersteuning, apparaattoewijzing, belasting van de video-engine, het geheugengebruik en het...

Hoe je kunt bepalen of een Plex-fout door de client of de server wordt veroorzaakt
Reproduceer hetzelfde item op een andere client, vergelijk het sessiepad en verzamel pas serverbewijs nadat de scope heeft uitgewezen waar de fout daadwerkelijk zit.

Plex-cache en tijdelijke opslag voor transcodering configureren
Bescherm de permanente Plex-status door tijdelijke transcodebestanden op geschikte lokale opslag te plaatsen en controleer vervolgens het opruimen, de beschikbare ruimte en het gedrag...

