Time Machine löper mindre risk att överge en befintlig NAS-historik när delningens säkerhetskopieringsidentitet bevaras innan du byter namn på, bygger om eller migrerar delningen.
En nätverksdestination för Time Machine är mer än en mapp som innehåller ett sparsebundle. Mac-datorn kan även vara beroende av den annonserade nätverksvolymen, SMB-funktionerna, delningssökvägen, autentiseringsuppgifterna och en volymidentifierare på tjänstesidan. Innan du ändrar NAS-enheten bör du dokumentera dessa identitetssignaler och skydda det befintliga sparsebundlet. Bygg sedan om eller byt namn på ett lager i taget och kontrollera att Mac-datorn fortfarande känner igen den avsedda destinationen innan du tillåter att en ny säkerhetskopiering startar.
Dokumentera den aktuella nätverksdestinationen före underhåll
Spara NAS-värdnamnet, SMB-adressen, delningsnamnet, kontot, den valda Time Machine-destinationen, sparsebundle-namnet och den aktuella storleken på säkerhetskopieringen. Dokumentera även hur delningen upptäcks, till exempel via Bonjour-annonsering eller en manuellt monterad SMB-sökväg.
Apple förklarar att en nätverksdisk för Time Machine väljs som nätverksdestination, inte bara är en valfri mapp som råkar innehålla säkerhetskopieringsfiler.
Skapa en ögonblicksbild av NAS-enheten eller en oberoende kopia av sparsebundlet innan du ändrar delningsdefinitionen. Då har du en återställningspunkt om den ombyggda tjänsten skapar en annan destinationsidentitet eller om Mac-datorn börjar skapa en ny historik.
Bevara Time Machine-volymens UUID där NAS-enheten stöder det
Om NAS-enheten visar ett UUID för Time Machine-volymen eller en liknande beständig identifierare ska du dokumentera den innan du tar bort eller återskapar SMB-delningen. Utgå inte från att samma synliga delningsnamn återskapar samma identitet.
TrueNAS dokumenterar att dess UUID för Time Machine identifierar volymen, och att skapande eller uppdatering av en delning med ett null-värde kan generera ett nytt UUID.
Återställ den tidigare identifieraren endast när den ombyggda delningen verkligen representerar samma säkerhetskopieringsdestination och den gamla serverinstansen inte längre är aktiv. Om samma UUID dupliceras på två aktiva destinationer uppstår en egen tvetydighet.
Se till att Time Machine-funktionerna för SMB är aktiverade på den ombyggda delningen
Det räcker inte att återskapa en vanlig SMB-delning på samma filsystemssökväg. Bekräfta att den ombyggda delningen fortfarande annonserar stöd för Time Machine och de Apple-specifika SMB-tillägg som Mac-datorn förväntar sig.
Sambas modul vfs_fruit anger att stöd för Time Machine annonseras via delningens FULLSYNC-funktion och mDNS-registrering där detta stöds.
Jämför de gamla och nya inställningarna för Samba- eller NAS-delningen innan du återansluter Mac-datorn. Om funktionen har ändrats ska du först korrigera serverns presentation i stället för att ta bort eller byta namn på sparsebundlet.
Återanvänd inte en volymidentifierare utan eftertanke
En bevarad nätverksvolymidentifierare är bara användbar när den hänvisar till samma logiska säkerhetskopieringsdestination. Om du klonar den gamla delningen till en andra aktiv NAS får de båda servrarna inte låtsas vara exakt samma Time Machine-volym.
Netatalk varnar för att dess volym-UUID ger robust åtskillnad och inte bör redigeras eller kopieras till en annan server utan eftertanke.
Under migreringen ska endast en destination åt gången vara auktoritativ. Ta den ersättande destinationen online med den bevarade identiteten först när den tidigare tjänsten är offline och kopieringen av sparsebundlet är slutförd.
Bevara Bonjour och valet av delning under övergången
Dokumentera vilken delad mapp som uttryckligen har angetts för Time Machine och om Bonjour annonserar den mappen. När NAS-enheten har byggts om ska du kontrollera att samma mapp publiceras innan du väljer den igen på Mac-datorn.
Synologys aktuella vägledning kräver att administratörer anger Time Machine-mappen och aktiverar Bonjour-sändning för Time Machine när den upptäcktsvägen används.
Om NAS-värdnamnet måste ändras ska du först bekräfta att den avsedda delningen kan nås via den nya SMB-sökvägen och fortfarande innehåller det skyddade sparsebundlet. Låt inte en tom ersättningsdelning bli den första destinationen som Mac-datorn ser.
Testa den befintliga historiken innan automatiska säkerhetskopieringar återupptas
Pausa automatiska säkerhetskopieringar, anslut igen till den ombyggda destinationen, bekräfta att det gamla sparsebundlet är synligt och bläddra bland eller återställ en känd fil från den tidigare historiken. Kontrollera delningen så att ett andra sparsebundle inte skapas under den första kontrollerade säkerhetskopieringen.
ASUSTOR rekommenderar SMB för Time Machine-säkerhetskopieringar på NAS-system som stöds, vilket understryker att serverns Time Machine-specifika SMB-presentation är en del av destinationen.
Underhållet är slutfört när Time Machine fortsätter på den befintliga historiken och inget andra sparsebundle visas. Den relaterade ZimaSpace-artikeln om ett nytt sparsebundle för Time Machine är återställningsalternativet om identiteten inte bevarades och Mac-datorn redan har startat en ny säkerhetskopiering.
Vanliga frågor
Räcker det att behålla samma SMB-delingsnamn?
Nej. Det synliga namnet är bara en av flera signaler. NAS-enheten kan återskapa delningen med andra Time Machine-funktioner, annan tjänsteannonsering, andra autentiseringsuppgifter eller en annan volymidentitet.
Bör jag byta namn på det befintliga sparsebundlet så att det matchar den ombyggda NAS-enheten?
Inte som en förebyggande genväg. Bevara bundle-filen först och håll destinationsidentiteten stabil. Att byta namn på avbildningen uppdaterar inte automatiskt de samband som Time Machine använder.
Kan jag testa den ombyggda delningen medan den gamla Time Machine-servern fortfarande är aktiv?
Var försiktig. Två aktiva destinationer som presenterar samma logiska identitet kan förvirra upptäckten och göra det oklart vilket sparsebundle som uppdateras. Föredra en kontrollerad övergång med en enda auktoritativ server.
Support och tips
Mer att läsa

Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.

Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.

Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.

