Een USB-back-uprepository naar een nieuw koppelpunt verplaatsen zonder de incrementele geschiedenis te verbreken

Het verplaatsen van een USB-back-uprepository naar een nieuw mountpad is veilig wanneer de repository zelf intact blijft en de back-uptaak er bewust opnieuw mee wordt verbonden.

De gevaarlijke fout is het nieuwe pad behandelen als een nieuwe bestemming en de back-upapplicatie naast de oude repository een lege repository laten initialiseren. Voordat je labels, mountregels of de directory-indeling wijzigt, leg je de fysieke bestandssysteemidentiteit, de hoofdmap van de repository, de repository-ID (als de tool die beschikbaar stelt), het versleutelingsmateriaal, de taakconfiguratie en het laatst bruikbare herstelpunt vast. Verplaats of mount daarna de bestaande repository als één geheel en controleer vóór de volgende schrijfactie of de applicatie de eerdere geschiedenis herkent.

Leg de bestaande repository vast voordat je het pad wijzigt

Sla de huidige mountbron, de UUID of het label van het bestandssysteem, de repositorymap, de taaknaam, de locatie van de versleutelingssleutel of het wachtwoord en de eigen identificatie van de repository op, als de back-uptool die beschikbaar stelt. Noteer meerdere recente snapshots of archieven als referentie.

Kopia maakt onderscheid tussen het aanmaken van een repository en verbinding maken met een bestaande repository. Dat onderscheid moet je tijdens het wijzigen van het mountpad behouden.

Begin pas met de verplaatsing wanneer je de oude geschiedenis kunt identificeren zonder alleen op het mountpad te vertrouwen. Als je uitsluitend het pad hebt vastgelegd, kan een later daar gemounte tweede USB-schijf bedrieglijk geldig lijken.

Verplaats de repository als één compleet geheel

Stop de back-uptaak en alle processen voor opschonen, comprimeren, controleren of herstellen voordat je repositorybestanden verplaatst. Kopieer of mount de volledige hoofdmap van de repository, inclusief indexen, configuratie, packs, vergrendelingen, daar opgeslagen sleutels en tool-specifieke metadata.

Borg beschrijft zijn repository als een gestructureerde transactionele opslag met repositorymetadata naast back-upgegevens. Alleen zichtbare bestanden die op archieven lijken kopiëren is daarom geen veilig model voor een verplaatsing.

Laat de oorspronkelijke repository ongewijzigd totdat het nieuwe pad een alleen-lezen lijstweergave of controle doorstaat. Open de oorspronkelijke en gekopieerde exemplaren niet voor normale schrijfacties wanneer de tool ze als dezelfde repository-identiteit beschouwt.

Wijzig het bestemmingspad zonder een nieuwe geschiedenis te initialiseren

Werk de bestaande taak of repositoryverbinding bij naar het nieuwe bestandssysteempad. Als de interface opties biedt zoals Create versus Connect, Import, Relink of Use Existing, kies dan de optie voor een bestaande repository en controleer de bestemming voordat je opslaat.

Beheerders van Duplicati leggen uit dat je na het verplaatsen van een bestaande opslag de bestemming kunt bewerken en kunt doorgaan wanneer de taakdatabase naar de verplaatste opslag verwijst.

Als de applicatie onmiddellijk aanbiedt om een lege bestemming te initialiseren, annuleer dan. Dat bewijst dat de oude repository nog niet is herkend; initialisatie kan een tweede geschiedenis aanmaken en latere opruiming onduidelijk maken.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Houd er rekening mee dat sommige tools een verplaatste repository detecteren

Een back-upclient kan meer onthouden dan alleen de inhoud van de repository. Lokale caches kunnen een repository-identiteit aan de vorige locatie koppelen en expliciete goedkeuring vragen wanneer dezelfde repository ergens anders verschijnt.

Een migratiegeval met Duplicacy en een gewijzigd mountpad draait om een verplaatste repository opnieuw koppelen. Dit laat zien waarom je een gewijzigd repositorypad als een relink moet behandelen en niet als een nieuwe initialisatie.

Keur de verplaatsing pas goed nadat je de repository-identiteit, de verwachte snapshots, de versleutelingsstatus en het USB-bestandssysteem hebt gecontroleerd. Een waarschuwing op de verkeerde schijf is een reden om te stoppen, niet het bewijs dat de software overdreven voorzichtig is.

Geef het USB-bestandssysteem een stabiele mountidentiteit

Zodra de repository is herkend, koppel je het fysieke USB-bestandssysteem aan een vast pad dat door de beheerder wordt beheerd, met een geschikte persistente identifier. Koppel geplande back-ups niet aan de volgorde waarin /dev/sdX-apparaten worden gedetecteerd of aan een mountmap die bij een desktopsessie hoort.

Linux-tools kunnen bestandssystemen identificeren aan de hand van een stabiel label of een UUID. Daardoor kan hetzelfde repositorypad blijven werken wanneer de apparaten in een andere volgorde worden gedetecteerd.

Als je bewust een bestandssysteemlabel wijzigt, werk dan de mountregel bij en test deze voordat je de back-ups opnieuw inschakelt. De back-upapplicatie moet dezelfde hoofdmap van de repository blijven zien, ook wanneer het leesbare label verandert.

Controleer de geschiedenis vóór de eerste schrijfactie na de verplaatsing

Mount de USB-schijf op het nieuwe pad, maak verbinding met de bestaande repository, geef eerdere snapshots weer, controleer het meest recente herstelpunt en herstel één klein bestand naar een tijdelijke map. Voer pas daarna de eerste nieuwe back-up uit.

Een restic-gebruiker merkt op dat een lokale repository kan worden hernoemd en opnieuw kan worden gekoppeld. Dit bevestigt dat de geschiedenis bij de inhoud van de repository hoort en niet bij de schrijfwijze van één mountpad.

De verplaatsing is voltooid wanneer oude snapshots doorbladerbaar blijven, een testherstel werkt en de nieuwe back-up aan dezelfde geschiedenis wordt toegevoegd. Het gerelateerde ZimaSpace-artikel over USB-mountpaden die na een herstart veranderen beschrijft de oplossing wanneer de padwijziging ongepland was in plaats van het gevolg van een gecontroleerde verplaatsing van de repository.

Veelgestelde vragen

Breekt het wijzigen van het label van een USB-volume automatisch de back-upgeschiedenis?

Niet noodzakelijk. Het wordt een probleem wanneer de mountregel of back-uptaak dat label gebruikt als onderdeel van de bestemmingsidentiteit en de repository daardoor niet meer op het verwachte pad wordt gevonden.

Moet ik alleen de map met de meest recente back-up naar het nieuwe pad kopiëren?

Nee, niet bij repositorygebaseerde back-uptools. Houd de volledige repositorystructuur bij elkaar, omdat indexen, catalogi, packbestanden, sleutels en oudere herstelpunten onderling afhankelijk kunnen zijn.

Kan ik de oude en nieuwe kopie van de repository tegelijkertijd online houden?

Houd de oude kopie als bron voor terugdraaien, maar vermijd onafhankelijke schrijfacties naar twee gekloonde exemplaren met dezelfde repository-identiteit, tenzij de back-uptool die werkwijze uitdrukkelijk ondersteunt.