Sikkerhetskopi av WordPress – fra kopi til gjenoppretting

En WordPress-backup må kunne bygge opp et fungerende nettsted, ikke bare hente tilbake noen bilder eller innlegg. Det betyr at filer, database og nødvendig konfigurasjon må høre sammen, være tilgjengelige utenfor produksjonskontoen og være prøvd i en full gjenoppretting.

Dette må være med

WordPress.org deler en vanlig sikkerhetskopi i to hoveddeler: WordPress-filene og databasen. Begge er nødvendige for å gjenopprette et typisk nettsted.

Filene

Filkopien bør omfatte:

• wp-content/uploads/ med bilder og dokumenter
• aktive og nødvendige temaer
• utvidelser, inkludert eventuelle mu-plugins
• egen kode og statiske filer
• wp-config.php
• serverregler som .htaccess der de brukes
• språkfiler og andre installasjonsspesifikke filer

WordPress-kjernen kan lastes ned på nytt fra WordPress.org, men en komplett filkopi gjør det enklere å bevare riktig helhet og undersøke hva som var installert. Ikke bruk en gammel, mulig kompromittert kjerne som eneste kilde ved gjenoppbygging etter et angrep.

Databasen

Databasen inneholder blant annet:

• sider, innlegg og revisjoner
• brukere og roller
• nettstedinnstillinger
• navigasjon og metadata
• skjemadata dersom utvidelsen lagrer dem lokalt
• ordre og kunder i en nettbutikk
• innstillinger og data opprettet av temaer og utvidelser

Å laste ned WordPress-mappen tar normalt ikke kopi av MySQL- eller MariaDB-databasen. Databasen må eksporteres separat og knyttes til filsettet fra omtrent samme tidspunkt. WordPress.org beskriver hvorfor filer og database må behandles som ett backupsett .

Hvor ofte bør WordPress sikkerhetskopieres?

Bruk hvor mye data dere tåler å miste som utgangspunkt, ikke en universell «daglig»-regel.

Filer og database kan ha ulik endringstakt, men gjenopprettingen må gi en konsistent tilstand. En database fra klokken 14 kombinert med opplastinger fra forrige natt kan for eksempel referere til bilder som ikke finnes.

Les den generelle veiledningen om RPO, RTO, oppbevaring og uavhengig lagring før frekvensen bestemmes.

Tre måter å ta WordPress-backup på

1. Backup hos hostingleverandøren

Serverbasert backup kan fungere selv om WordPress-installasjonen er ødelagt. Det er nyttig, men sjekk detaljene:

• Inngår både filer og alle databasetabeller?
• Tas de som et konsistent sett?
• Hvor ofte tas kopien, og hvor lenge beholdes den?
• Er den isolert fra produksjonskontoen?
• Kan dere laste ned en portabel kopi?
• Kan dere gjenopprette selv, eller må support gjøre det?
• Hva er pris og forventet tid for gjenoppretting?

En kopi av hele serveren er ikke nødvendigvis rask eller selektiv å gjenopprette. Be om dokumentasjon i stedet for å anta at ordet «backup» dekker behovet.

2. Backup-utvidelse i WordPress

En utvidelse kan automatisere databaseeksport, filarkiv og overføring til ekstern lagring. Velg etter egenskaper, ikke popularitet alene:

• støtter den både filer og database?
• kan kopien lagres utenfor samme hostingkonto?
• krypteres overføring og eventuelt innhold?
• varsler den ved feil?
• kan den gjenopprette på en tom installasjon?
• håndterer den størrelsen og tidsgrensene på hostingen?
• er gjenopprettingsfunksjonen inkludert i valgt lisens?

En backupjobb som kjører inne i WordPress kan feile når PHP-tid, minne, diskplass eller selve nettstedet svikter. Bruk derfor ikke en pluginstatus som eneste kontroll.

3. Manuell eller skriptet eksport

Med WP-CLI kan en autorisert administrator eksportere hele databasen:

wp db export wordpress-backup.sql --add-drop-table

Kommandoen bruker databaseopplysningene i wp-config.php. WP-CLI dokumenterer wp db export og muligheten til å eksportere alle eller valgte tabeller.

Filene kopieres separat med SFTP, SSH eller hostingleverandørens filverktøy. Flytt resultatet til beskyttet lagring, kontroller at arkivet kan åpnes, og slett løse eksportfiler fra webområdet. En .sql-fil kan inneholde personopplysninger, passordhash og sikkerhetskritisk konfigurasjon.

phpMyAdmin kan også eksportere databasen. Pass på at alle WordPress-tabellene er med; utvidelser kan ha opprettet tabeller som ikke følger standardnavnene dere forventer.

Oppbevar kopier i flere generasjoner

Behold mer enn siste kjøring. En kompromittering eller innholdsfeil kan oppdages etter at flere nyere kopier allerede inneholder problemet.

En plan kan kombinere:

• korte intervaller for de siste timene eller døgnene
• daglige kopier for de siste ukene
• ukentlige eller månedlige kontrollpunkter lenger tilbake
• en ekstra kopi før større oppdateringer og migreringer

Oppbevar minst én versjon utenfor samme hostingkonto og med andre administratorrettigheter. Begrens hvem som kan slette kopier, og varsle ved endringer i oppbevaringspolicyen.

WordPress-backup for WooCommerce

En nettbutikk krever mer forsiktighet enn en brosjyreside. Når en gammel database gjenopprettes, kan nyere ordre, lagerendringer, refusjoner og kundedata forsvinne eller bli inkonsistente med betalingstjenesten.

Før restore må dere:

1. stanse eller kontrollere nye bestillinger
2. dokumentere siste gyldige ordre i WordPress og hos betalingsleverandøren
3. velge riktig gjenopprettingspunkt
4. planlegge hvordan data etter tidspunktet skal avstemmes eller importeres
5. teste lager, e-post, betaling og webhooks etterpå

Et vanlig døgnsnapshot er ikke automatisk en forsvarlig løsning for en aktiv butikk. Avklar behov for hyppige databasekopier, transaksjonslogger eller en spesialisert løsning med leverandøren.

Slik tester dere gjenoppretting

Test i et isolert miljø som ikke kan sende kundemeldinger, ta betaling eller indekseres av søkemotorer.

1. Velg et dokumentert backupsett med filer og database.
2. Opprett et rent miljø med kompatibel PHP- og databaseversjon.
3. Gjenopprett WordPress-filene.
4. Opprett database og importer eksporten.
5. Oppdater wp-config.php dersom databaseopplysningene er endret.
6. Tilpass URL-er bare når testmiljøet bruker et annet domenenavn.
7. Test innlogging, sider, bilder, skjema, søk og kritiske integrasjoner.
8. Mål tiden og dokumenter avvik.
9. Slett eller beskytt testmiljøet etterpå.

WordPress.org anbefaler vanligvis filer først og database etterpå ved gjenoppretting . En leverandørs verktøy kan bruke en annen koordinert prosess; følg da dokumentasjonen og kontroller sluttresultatet.

Etter et hackerangrep

Ikke legg en gammel kopi ukritisk tilbake på samme kompromitterte miljø. Dere må først forstå omtrent når hendelsen startet og stenge angrepsveien.

En tryggere rekkefølge er:

• isoler den rammede installasjonen og bevar nødvendige logger
• velg en kopi fra før kompromitteringen
• bygg opp et rent og oppdatert miljø
• installer ren WordPress-kjerne og rene utvidelser fra betrodde kilder
• gjenopprett innhold og nødvendige tilpasninger
• roter passord, nøkler, salts og integrasjonshemmeligheter
• kontroller brukere, administratorer, planlagte jobber og endrede filer
• overvåk tett etter publisering

En restore fjerner ikke sårbarheten som slapp angriperen inn. Den må lukkes før nettstedet settes tilbake i drift.

Hva inngår hos Vymo?

Vymos standardtilbud er ikke WordPress-hosting og inkluderer ikke en dokumentert WordPress-backup- eller gjenopprettingstjeneste. Vi lager og hoster én enkel bedriftsnettside, men publiserer foreløpig ikke et fast backupintervall eller en selvbetjent restorefunksjon for standardtilbudet.

Trenger dere WordPress, må hosting, vedlikehold, sikkerhetskopi og gjenopprettingsansvar avklares som en separat leveranse. Beskriv WordPress-behovet , eller velg den enkle nettsiden dersom dere ikke trenger WordPress-plattformen.