Artikkelen forklarer hvorfor backup og restore bør bo i kontrollpanelet, men beskyttes med klare barrierer. Den tar for seg rollebasert tilgang, navngitte snapshots, restore-test, logging, bekreftelser og forskjellen mellom backup som fil og backup som faktisk…
Backup er ikke trygghet før den kan gjenopprettes. Samtidig er restore en av de mest risikable knappene et kontrollpanel kan ha. Derfor bør backup og restore være tilgjengelig for riktige roller, men aldri være trivielt å bruke.
Backup må være nær driften
Et lite CMS trenger ofte rask tilgang til backup før oppdateringer, import og designendringer. Hvis backup bare finnes som en manuell serverrutine, blir den fort glemt når tempoet er høyt. Derfor gir det mening å ha backupfunksjon i kontrollpanelet.
Restore må ha friksjon
Restore kan overskrive fungerende data med gamle data. Det bør derfor kreve høyere rolle, tydelig bekreftelse, synlig snapshot-navn og helst en ekstra kontroll før handlingen kjøres. Friksjon er ikke dårlig brukeropplevelse når handlingen er farlig.
En backup uten restore-test er bare håp
Det holder ikke å ha en fil. Systemet må vite at backupen kan leses, importeres og brukes. Jevnlige restore-tester i et trygt miljø er det som gjør backup til reell beredskap.
Navngitte snapshots gjør feilsøking enklere
En backup bør ha navn, dato, fase, bruker og formål. Da kan man skille mellom backup før redesign, før SQL-import og før kontrollpanelendring. Uten navn blir alle filer like når noe haster.
WEBoracle-vurdering
WEBoracle bør ha backup lett tilgjengelig for administratorroller, men restore bør beskyttes strengere. Kontrollpanelet kan vise historikk, filstørrelse, tidspunkt og rapport, men selve gjenopprettingen bør kreve eksplisitt bekreftelse.
Konklusjon
Backup og restore hører hjemme nær driften, men ikke som ufarlige knapper. Et godt kontrollpanel gjør backup enkelt, restore kontrollert og gjenoppretting testbar.