Een Plex-back-up is pas bewezen wanneer een schone instantie de serverstatus, machtigingen, bibliotheken en representatieve weergave vanaf die kopie kan herstellen.
Bestandsaantallen en geslaagde kopieeropdrachten zijn geen hersteltests. Gebruik een geïsoleerde runtime, dubbele of alleen-lezen mediapaden en gedocumenteerd eigenaarschap, zodat het herstel geen verborgen afhankelijkheden uit productie overneemt. Test zowel een recent als een ouder herstelpunt wanneer de bewaartermijn bedoeld is om bescherming te bieden tegen fouten die pas laat worden ontdekt.
Begin met een schone runtime
Een hersteltest moet beginnen zonder dat de actieve container, database of het metadatapad is gekoppeld. Anders kan de test slagen omdat de productiestatus nog beschikbaar is.
Onafhankelijk hersteltesten verifiëren een back-up door bruikbaar servicegedrag opnieuw op te bouwen, in plaats van alleen te bevestigen dat er een archief bestaat.
Maak een wegwerpcontainer of -host en koppel alleen de gekopieerde back-up plus niet-destructieve toegang tot media. Leg elke handmatige stap vast die nodig is om de aanmeldpagina te bereiken.
Verifieer identiteit, bibliotheken en machtigingen
De server kan starten terwijl bibliotheekrelaties, accountbeleid of schrijfmachtigingen toch verloren zijn gegaan. Neem dit gedrag op in de acceptatietest.
Een correcte UID- en GID-toewijzing is noodzakelijk wanneer een herstel in containers de status verplaatst naar een host met ander eigenaarschap.
Open representatieve bibliotheken, voer een onschadelijke statuswijziging uit en controleer beperkte en onbeperkte accounts. Verbeter de herstelprocedure in plaats van ongedocumenteerde rootmachtigingen toe te passen.
Test meer dan alleen de recentste kopie
De nieuwste back-up kan zijn gemaakt na stille beschadiging of een slechte update. Bewaring is alleen nuttig wanneer ook een ouder, bekend goed herstelpunt kan worden geselecteerd en hersteld.
Een nuttige back-upgeschiedenis bewaart bekend goede herstelpunten van vóórdat de fout in het systeem terechtkwam.
Herstel volgens een vast schema één recent en één ouder herstelpunt. Als uitsluitend de nieuwste kopie ooit wordt getest, is de oudere bewaarlaag nog niet bewezen. Een gedocumenteerde mediaservertopologie voor thuis moet het hersteldoel, mediapad en storingsdomein van de back-up duidelijk maken voordat zich een echt incident voordoet.
Meet de hersteltijd
Een technisch geslaagd herstel kan nog steeds de maximale uitvaltijd voor het huishouden overschrijden. Meet de tijd en identificeer de langzaamste handmatige of opslagstap.
Veel hostmigraties slagen of mislukken door statusmigratie, vooral wanneer applicatiegegevens en mountpaden consistent moeten blijven.
Leg de tijd vast vanaf een lege runtime tot gevalideerde weergave. Herhaal dit nadat u de opslagindeling, machtigingen of back-upsoftware hebt gewijzigd, zodat de schatting betrouwbaar blijft.
Ondersteuning & Tips
Meer om te lezen

Moet je een live back-up van Jellyfin maken of de service eerst stoppen?
Geef de voorkeur aan back-ups van gestopte services voor eenvoud; gebruik live snapshots alleen wanneer de applicatiestatus consistent wordt vastgelegd en herstelprocedures zijn getest.

Waarom draait Jellyfin zo warm of luidruchtig als niemand streamt?
Hittesterkte tijdens inactiviteit wijst meestal op achtergrondwerk of een belasting door gedeelde hosting. Identificeer daarom het actieve proces en de geplande taak voordat je...

Wanneer moet je Jellyfin opnieuw opbouwen in plaats van repareren?
Kies voor opnieuw opbouwen in plaats van repareren wanneer runtime-drift het probleem is en de persistente status is geback-upt; verwijder de enige goede database...

