Een back-up van Home Assistant is pas bewezen wanneer een afzonderlijke instantie deze kan herstellen en de identiteiten, configuratie, integraties, geschiedenis en hersteltijd kan leveren die het huishouden nodig heeft.
Een geslaagde archiveringstaak verifieert alleen de aanmaak, niet het herstel. Gebruik een geïsoleerde VM, een reserveapparaat of een losgekoppeld netwerksegment; laat de productieomgeving draaien; bereid de encryptiesleutel en het overeenkomstige installatiepad voor; en test vervolgens zowel het technisch opstarten als echte huishoudelijke functies. Stop voordat gekloonde automatiseringen, radio's of webhooks acties kunnen uitvoeren op productieapparaten.
Kies de back-up en definieer een geslaagde test
Selecteer een recente geplande back-up en een ouder herstelpunt, en noteer de grootte, aanmaaktijd, opgenomen componenten, opslaglocatie, encryptiestatus en checksum, indien beschikbaar. Definieer de maximale hersteltijd en de exacte configuratie, gebruikers, automatiseringen, geschiedenissen, add-ons en geheimen die moeten terugkeren.
Een geslaagde test kan niet alleen betekenen dat de inlogpagina verschijnt. De test moet de huishoudelijke functies benoemen die van belang zijn, zoals lokale lichtbediening, één kritieke automatisering, dashboards voor standaardgebruikers, de bewaartermijn van de database en toegang tot een externe broker of database.
Laat de voorbereidingsfase mislukken als het archief of de herstelsleutel alleen op de productieschijf staat, als het installatietype dat artefact niet rechtstreeks kan herstellen of als geen geïsoleerd doel dubbele acties kan voorkomen. Corrigeer die omstandigheden voordat je de productieomgeving aanraakt.
Herstellen naar een geïsoleerd doel
Maak een schoon doel met een compatibele architectuur en voldoende opslagruimte, isoleer het netwerk van productieapparaten en behoud een consoleverbinding voor probleemoplossing. Start het herstel met een kopie van het archief, niet met de enige bewaarde back-up.
Zelfs een geïsoleerde hersteltest kan netwerktoegang voor de supervisor vereisen. Ontwerp de isolatie zo dat noodzakelijke installatiebronnen bereikbaar blijven zonder productieapparaten bloot te stellen.
Als het herstel vóór het opstarten mislukt, noteer dan de exacte fase, archieffout, het resultaat van de sleutelcontrole, de vrije ruimte, de doelversie en het installatietype. Upload of wijzig de enige kopie niet herhaaldelijk; bewaar deze en test een tweede bekende back-up om archiefschade van incompatibiliteit van het doel te kunnen onderscheiden.
Controleer de toestand, afhankelijkheden en huishoudelijke functies
Vergelijk na het opstarten de gebruikers, dashboards, entiteiten, automatiseringen, helpers, verwijzingen naar geheimen, databasegeschiedenis, add-ons en integratiestatus met de testlijst. Houd radio's losgekoppeld of gebruik veilige vervangers totdat de gekloonde instantie geen dubbele opdrachten meer kan verzenden.
Kunnen herstellen op tijdelijke hardware bewijst meer dan kopieën op meerdere plaatsen opslaan zonder een echte herstelpoging.
Een ontbrekende externe database, broker, DNS-record, certificaat of netwerkshare maakt deel uit van het herstelresultaat en is geen losstaand ongemak. Documenteer de afhankelijkheid en de volgorde die nodig is om deze te herstellen.
Meet het herstel en sluit de test af
Voer de gedefinieerde controles voor lokale bediening en automatiseringen uit, start de testinstantie tweemaal opnieuw op en bevestig dat de herstelde toestand behouden blijft. Noteer de tijd van een leeg doel tot een bruikbare dienst, handmatige stappen, niet-beschikbare functies en elke inlogmethode of afhankelijkheid die afzonderlijk moest worden hersteld.
Vergelijk het resultaat met de herstelcontrole vóór het uitfaseren voordat je hardware wijzigt of het bronsysteem buiten gebruik stelt.
Slaag alleen wanneer de vereiste functies en gegevens na een herstart binnen het hersteldoel behouden blijven. Vernietig of isoleer de kloon nadat het bewijs is vastgelegd, corrigeer een mislukte back-upscope of opslag van de sleutel, maak een nieuwe back-up en herhaal de test voordat je het productieherstelpad veilig verklaart.
Plan de volgende controle voordat het systeem verandert
Noteer de geïdentificeerde back-up, de bronversie, het doeltype, de hersteltijd, ontbrekende afhankelijkheden en het eindoordeel. Bewaar dit bewijs naast de herstelprocedure en niet in de productie-instantie die deze mogelijk moet vervangen.
Plan de volgende test na een wezenlijke wijziging in opslag, installatie, encryptie, database of add-on, en met regelmatige tussenpozen die passen bij de hersteltolerantie van het huishouden. Een bestand dat na de test is gemaakt, valt niet automatisch onder het vorige resultaat.
De volgende test mag een kleiner representatief doel gebruiken, maar moet nog steeds ontsleuteling, opstarten, kritieke identiteiten en één end-to-end huishoudelijke functie bewijzen. Alleen het archief inspecteren kan die controle op serviceniveau niet vervangen.
Ondersteuning & Tips
Meer om te lezen

Hoe optimaliseer je Immich-databaseverbindingen voor gelijktijdige containers?
Verhoog max_connections niet als eerste. Meet de Immich-sessies, tel de vraag van elke container bij elkaar op, behoud ruimte voor beheerders en stem alleen...

Dubbele taken of imports in Immich voorkomen
Scheid herhaalde taken van dubbele assets. Gebruik één canoniek ingestiepad, beheer retries en padwijzigingen en test vervolgens opnieuw invoeren op een kleine groep.

Immich herstellen nadat het databasevolume vol raakt
Verwijder nooit PostgreSQL-WAL om ruimte vrij te maken. Stop schrijfbewerkingen van Immich, behoud de databasestatus, voeg veilig extra opslagcapaciteit toe, herstel PostgreSQL en voorkom...

