Asensin lisäosan Advanced Database Cleaner (Younes JFR.), joka on näppärä työkalu nopeaan tietokannan siivoukseen. Kaikki oli hyvin, paitsi seuraavana päivänä. Kaikki luonnokset olivat hävinneet. Työtunteja hävisi paljon. Syyllinen oli mainittu lisäosa, joka oli asennuksessa pyytämättä laittanut croniin automaattisen siivouksen.

Jos se olisi tyytynyt vaikka transientien siivoukseen, roskakorin tyhjentämiseen ja tietokannan järjestämiseen, niin kaikki olisi ollut hyvin. Mutta lisäosa poisti myös kaikki draftit ja versiot, joka ei ollut todellakaan ok. Kirosin hiljaa mielessäni ja palautin tietokannan edellisen varmuuskopion.

Törmäsin toiseen ongelmaan. Olin aloittanut artikkelit varmuuskopioinnin jälkeen, mutta ennen siivousta. Ei ollut mitään palautettavaa ja varmuuskopiointi ei pelastanut mitään. Mutta minulla sentään oli varmuuskopiot, suurimmalla osalla ei ole mitään.

Vaivaa ja laiskuutta

Suurin syy backuppien tekemättömyyteen on laiskuus ja vahva luotto siihen, että mitään ei tapahdu. Olen maksanut kohtuullisen ison laskun samasta asenteesta. Henkilökohtaisesti siten, että minulla ei ole enää menneisyydestäni mitään dokumentteja jäljellä. Olen kuin tulipalon jäljiltä, mutta minulla tilanteen aiheutti maastamuutto, jossa muuttorahti tuhoutui.

Olin ollut kaukaa viisas ja digitoinut vanhat valokuvat, todistukseni ja ylipäätään kaiken paperitavaran. Ne olivat turvassa ulkoisella kovalevyllä. Se ei paljoa lohduttanut siinä vaiheessa kun taapero tipautti sen lattialle.

Melkoinen määrä digikuvia sekä muuta dataa tuhoutui ukkosen käräytettyä kaiken. Kovalevyä ei saatu palautettua pelkällä elektroniikan vaihdolla, koska jännitepiikki tuli pahaan aikaa levykirjoituksen aikana.

Rahallisesti olen maksanut aika paljonkin, kun ensin WordPressin päivitys tuhosi tietokannan. Palautuksen olisi saanut tehtyä varmuuskopioista, joita ei ollut. Kyseessä oli yli tuhannen artikkelin wiki-tyyppinen sivusto. Sisältöä palauteltiin sitten selaisten välimuistitallennuksista ja netin arkistointipalveluista. Osa löytyi omalta koneelta, koska olin kokeillut wget-ohjelmaa.

Toisella kertaa sivusto murrettiin ja sisältö hävitettiin. Koska olen kovapäinen, niin silläkään kertaa varmuuskopioita ei ollut. Tarvitsen aina kolme oppituntia, joten kolmas kerta tuli, kun palveluntarjoajan laitteisto hajosi, eikä tietokantaa voitu palauttaa. Sain 50 taalan korvauksen noin 10 000 euron vahingosta – kyseessä oli bisnessaitti.

Nuo ovat viimeistä lukuunottamatta vuosien takaa. Silloin ei ollut mitään helppoa ja järkevää tapaa varmuuskopioida. Ensin piti kopioida sisältöä kymmenille korpuille. Kehitys kehittyi ja kaikki piti kopioida kymmenille CD- ja DVD-levyille. Vaivaa oli niin paljon, että ei sitä kukaan tehnyt. Ja vaikka tekikin, niin taatusti osa tallennusmediasta oli korruptoitunut, ja palautus pissi siihen.

Websivujen suhteen tilanne ei ollut aikoinaan paljoakaan parempi. Yhteydet olivat olivat useimmilla modeemipohjaisia ja jopa huimalla 14k4-vauhdilla siirto vei ikuisuuden – kunhan joku perheessä ei yrittänyt soittaa samaan aikaan. Ei sitä kukaan tehnyt, vaikka olikin esitelty ihme nimeltä kiinteä kuukausihinta.

Vaikka Nokia siirsikin kehityksen kelloa taaksepäin esitellessään 9600-vauhtisen mobiilidatan, niin talouksien nettiyhteyden nopeutuivat. Varmuuskopiointi ei ollut enää siirtoajoista kiinni. Pullonkaulaksi tuli helppous.

Pilvipalveluista ei oltu kuultukaan. Edelleenkin backup piti siirtää omalle koneelle. Toinen vaihtoehto oli tallentaa varmuuskopio webhotellin rakenteeseen. Se oli nopeudessaan ja vaivattomuudessaan houkutteleva vaihtoehto, koska WordPress-maailmaan oli esitelty huippukeksintö: automatisoidun varmuuskopion tekevä lisäosa. Itse hakemistorakennettahan (ja kuvia) ei edelleekään varmuuskopioitu, koska – niin silloin kuin nytkin – mikään ei ole niin kallista kuin webhotellien tallennustila.

Pro-puolellahan  RAM ja prosessorit ovat kalliita, mutta suurin osa käyttää kuluttajatason jaettuja palveluita, joissa nimenomaan kovalevytila maksaa. Ja maksaa vielä hieman enemmän. Jos olet kuullut väittämän, että mikään ei ole niin halpaa kuin tallennustila, niin se koskee vain ja ainoastaan HDD-tekniikalla toteutettuja kuluttajamarkkinoiden ulkoisia kovalevyjä. SSD-levythän taasen ovat naurettavan kalliita ja siksi läppärimaailma myy standardisti niin ahtaita koneita, että kännykkäkuvaaja saa ne alta aikayksikön tukkoon (koska ei siirrä kuviaan muualle).

Varsinaista varmuuskopintia ei koskaan tehdä samalle serverille kuin missä kopioitava on. Se on ajatuksena yhtä hölmö kuin kopioida tietokoneen valokuvakansio toiseen hakemistoon. Suojaa kylläkin vahingossa painetulta deleteltä, mutta ei kovalevyn tai käyttöjärjestelmän hajoamiselta. Sama asia verkkosivujen kohdalla.

Varmuuskopioinnin nykypäivä

Nykyään mitään esteitä varmuuskopioinneille ei ole. Pilvipalveluja on joka kulman takana ja jokainen laite osaa niitä hyödyntää. Ongelmia tulee vasta sitten kun varmuuskopioitavaa on terakaupalla – eikä tuo edes mikään harvinainen ongelma. Samaan tahtiin 4K-videoiden kanssa, jotka ovat suuremmalle osalle täysin hyödyttömiä, ja mobiilikameroiden päättömien pikseleiden kanssa, tiedostokoot ovat kasvaneet lähes hallitsemattomasti.

Kun lisäksi mitään ei poisteta, niin ollaan samassa jamassa kuin kaitafilmikuvaajat aikoinaan: kaikki nurkat ovat täynnä mediaa, joita kukaan ei koskaan käytä, mutta ne pitäisi saada johonkin, ja itku on valtava, jos ne häviävät.

Ensin varmuuskopioita ei tehty, koska tallennusmediat olivat niin pieniä. Sitten varmuuskopiota ei tehty, koska tiedostonsiirto oli niin hidasta. Nyt varmuuskopioita ei tehdä, koska siirrettävää dataa on liikaa.

On aivan sama, jos et ilman mitään syytä anna puhelimesi siirtää kuvia ja videoita pilveen turvaan. Se koskee vain sinua. Mutta jos pyörität verkkosivuja, niin varmuuskopioimattomuus kaataa sivustosi taatusti jossain vaiheessa koko muun maailman saavuttamattomiin. Useimmille tuo ei ole haluttu tilanne, koska sivuja tehdään nimenomaan muille ihmisille.

Omissa laitteissa voi joutua priorisoimaan.

• Saavatko varmuuskopiot maksaa
• Täytyyko kaikki varmuuskopioida

Tuo ei kuitenkaan koske verkkosivuja. Niissä kopioidaan aina kaikki ja useampaan paikkaan. Ei puututa hakkerointitason turvallisuuteen tai miten suojaudutaan valtiolliseen vahtimiseen tai yritysvakoiluun, koska jos nuo ovat sinulle oleellisia, niin lähtökohtaisesti et ole täällä tässä jutussa. Useampi paikka tarkoittaa sitä, että kopioit kaiken

• palvelun sisällä
• vähintään kahteen eri pilvipalveluun

Mitä sivustolta varmuuskopioidaan?

Varmuuskopiointi on nykyään automatisoitua. Tarkoittaa sitä, että jokin kello, usein cron, käynnistää backup-ohjelman, joka tekee kaavamaisesti jotain ennalta asetettua. Joutuu hieman miettimään mitä tehdään ja milloin. Kyse on osaksi tilan säästöstä, sillä samoja tiedostoja ei kannata varmuuskopioida kerta toisensa jälkeen, lisäksi joskus serverin tehot saattavat kyykätä isoissa varmuuskopioinneissa.

Yleensä kannattaa varmuuskopioida

• tietokanta usein, koska se on aina pienin, mutta myös tärkein
• omat tiedostot myös erikseen
• koko järjestelmä harvakseltaan

Tietokanta

Se, että kuinka usein varmuuskopio tietokannan, riippuu. Tällä sivustolla on sen verran hidas julkaisuvauhti, että kerta päivässä riittäisi. Mutta koska korjaan aika ajoin ulkonäköä ja säädän uudelleenohjauksia, sellaisia sisänsä aika pieniä säätöjä, niin tietokannan backup otettiin kahdesti päivässä.

Se toimi siihen asti, kunnes ei enää toiminut. Kun uutta oli luotu varmuuskopioinnin jälkeen, mutta rikkoutuminen tapahtui uuden sisällön jälkeen ennen seuraavaa varmuuskopiota, niin mitään uudesta ei jäänyt palautettavaksi. Säädin sen jälkeen tietokannan varmuuskopioinnin joka neljäs tunti tapahtuvaksi. Käytän samaa aikataulutusta aktiivisimmilla sisältösaiteilla ja olen havainnut sen toimivaksi kompromissiksi.

Oma verkkokauppa on sen verran hiljainen, että siellä riittää kerran tunnissa. Silloin riski sille, että vahingon sattuessa häviäisi turhan paljon, on minimaalinen. Jos joku tilaus katoaa kannasta, niin saan korjattua sen käsin. Yhdellä asiakkaalla tietokannan varmuuskopio ajettiin kerran viidessä minuutissa ja jossain vaiheessa se päivitettiin kerran minuutissa tapahtuvaksi – mutta hänellä oli huomattavan paljon liikennettä.

Tietokantakopion aikataulutus on vain yksi osa ratkaisua. Minuutin välein otettava varmuuskopio ei pelasta järjestelmää, jos jokin oleellinen virhe huomataan vasta viikon päästä. Silloin jokainen kopio viikon ajalta sisältää saman virheen. Tähän ei ole olemassa mitään oikeaa tai väärää ratkaisua, vaan se riippuu. Itselläni on jokaiselta sivustolta viikon aikajaksolta varmuuskopiot tallessa.

Hieman sivujuonteena, mutta GDPR:n alainen poistopyyntö koskee myös varmuuskopioita. Käytännössähän tietopoisto on ihan jumalattoman vaikeaa tehdä varmuuskopioista, vaikka se onkin mahdollista. Oma suhtautuminen on, että viikko on hyväksyttävä aikaväli tiedon poistumiseen. Onneksi tuo ei ole ihan jokapäiväinen asia.

Turvallisuus on suurempi kysymysmerkki. Useimmat backup-ohjelmat eivät lähtökohtaisesti salaa tietokantaa, joten se paikka, jossa niitä säilytetään, pitää olla turvallinen. Minä käytän säilönä Amazonin S3:a ja olen nähnyt painajaisia siitä, että tunnukseni tuonne murretaan. Silloin nimittäin vuotaa aika monenkin sivuston kaikki käyttäjätiedot, salasanoja lukuunottamatta.

Tämä on asia, jossa ei oikein voi voittaa. Jos kopio salataan, niin se saadaan auki vain salaukseen käytetyllä ohjelmalla. Jos tietokantakopio on paljasta sql:ää, joka on määrämalliin tehty tekstitiedosto, niin se saadaan takaisin oikeastaan ihan millä tahansa ohjelmalla, myös suoraan komentoriviltä.

Omat tiedostot

Varmuuskopioin WordPressissä omat tiedostot, eli käytännössä uploads-hakemiston erikseen kerran päivässä ja lisäksi käsin, jos on tullut isompi upload-ruuhka. Pelkästään siksi, että tietokannan lisäksi se on sellainen tiedostovarasto, jota ei ole muutoin oikein missään asioiden mennessä pahasti pieleen.

Luultavasti siksi, että olen aikoinaan menettänyt niin paljon valokuvia, niin pidän siitä kuukauden mittaisen ajanjakson kopiot tallessa. Tuo on liioittelua, tiedän sen, mutta nukun yöni paremmin. Varmuuskopioinnin vahva dokumentoimaton merkitys on olla nimenomaan unenlaadun varmistaja.

Omassa tavassani ongelma on siinä, että minulla on melkoisen iso määrä päällekkäisiä ja muuttumattomia tiedostoja. Yleensä tapa, jossa varmuuskopioidaan vain muuttunut tieto, on sarjaa huonot ideat. Silloin on lähes mahdotonta päättää palautusaikaa. Oikeammin, se on mahdollista fiksuilla backup-ohjelmilla, mutta käytännössä ja varsinkin WordPress-maailmassa, fiksuus on aika ajoin katoava luonnonvara. Tai kallis vaihtoehto. Mutta uploads-hakemiston kohdalla sitä kannattaa käyttää, niin saa hieman rajoitettua tallennettavan datan määrää.

Koko järjestelmä

Varmuuskopioin koko WordPress-asennuksen kerran päivässä. Aivan kaiken: WordPressin, lisäosat, uploads-hakemiston ja tietokannan. Sinällään ladattavaa sisältöä ei välttämättä tarvitse kopioida, koska WordPressin saa aina asennettua uudelleen (WP CLI:tä käyttäen todella vauhdikkaasti) ja lisäosatkin löytyvät. Jos sinulla on maksettuja, mutta lisenssinsä yliaikaiseksi päästäneitä lisäosia tai teemoja, niin älä koskaan luota mahdollisuuteen ladata ne uudestaan. On nimittäin sääntö, että maksun puuttessa sinua ei enää päästetä lataamaan, koska vanhaakaan versiota ei tarjota.

Olen kerran ollut tilanteessa, jossa tein tuo operaation. Asensin kaiken ja palautin vain omat tiedostot, maksetut lisäosat ja tietokannan. Se on niin työläs ja aikaavievä urakka, että ei enää koskaan. Joten säästääksesi hermojasi ja varsinkin työaikaasi, niin pidä aina käsillä palautettava versio koko järjestelmästä.

Pidän tallessa kahden viikon varmuuskopiot. Ehkä hieman turhan pitkä, varsinkin aktiivisilla sivustoilla. Hiljaisemmilla saiteilla, kuten täällä, saattaa helposti mennä viikko, että piipahdan. Jos sinä aikana mikä tahansa, vaikka WordPressin automaattinen turvallisuuspäivitys, on rikkonut paikat, niin haluan olla varma toimivan version löytymisestä.

Tuo oli muuten esimerkkinä hyvinkin kömpelö. Jos WordPressin päivitys rikkoo jotain, niin minor-päivityksissä yleensä tietokannan palautus riittää. Tai sitten rollaa WP CLI:n avulla takaisin edelliseen versioon – sekin on mahdollista.

Manuaalinen backup

Teen varmuuskopioita käsinkin. Yleensä tietokannan suhteen, mutta aika ajoin myös järjestelmän suhteen – varsinkin major-päivityksissä. Systeemi varmuuskopioituu napin painalluksella, eikä se hidasta sinällään töitäni. Joko haen sillä aikaa kupin kahvia tai käyn tupakalla. Silloin saan nollattua tilanteen, jos jokin lakkaa toimimasta.

Jos olet webhotellin asiakas, niin WP CLI ei ole sinulle yleensä vaihtoehto (mutta se on vahva syy siirtyä käyttämään virtuaaliserveriä eli VPS:ää). Jos pääset shelliin, ja saat jopa asennettua jotain Linux-ympäristössä, niin WP CLI on ehdottomasti näppärin ja nopein tapa.

Kun haluan ottaa nopeasti varmuuskopion tietokannasta, niin tämä tekee sen:

wp db export jokunimi.sql

Jos haluan palauttaa tietokannan, niin komennan:

wp db import jokunimi.sql

Isollakin saitilla tuo vie vain sekunteja.

Sen saa myös automatisoitua cronille, jolloin saa paikallisen varmuuskopion huomattavan helposti. Heikkous on siinä, että käsillä on silloin koko ajan vain viimeisin kopio. Sekin pelastaa monelta ongelmalta, mutta moinen ei saa olla ainoa vaihtoehto. Toki on mahdollista koodata scripti, joka laittaa esimerkiksi päiväyksen ja kellonajan tedostonimeen, jolloin ylikirjoitusta ei tapahdu, mutta se ei ole aiva läpihuutojuttu – ainakaan tavikselle, kuten minulle.

rsync

Virtuaaliservereillä rsync on järkevin tapa tehdä koko sivuston varmuuskopiot. Yksinkertainen bash-scripti, joka pitää sisällään rsyncin komentorotlan ja joka ajetaan ajastetusti cronilla – itseasiassa, tuo on rsync -komennon pohjimmainen tarkoituskin.

Kun halutaan kopioida uuteen paikkaan, niin tämä tekee sen ylikirjoittamatta vanhaa:

rsync -vh lähde/ kohde/

Tuolla saat nopeimman paikallisen kopion tehtyä. Ja jos haluat kopion toiselle serverille, niin ei se sen kummallisempi liike ole:

rsync -av -e ssh vanhan_polku/ root@uusi_ip:/polku/uuteen/

Itseasiassa hieman soveltamalla ohjetta WordPressin siirtämisestä saat tehtyä eräänlaisen köyhän miehen peilaamisen, mirrorin, jolloin saat minimaalisella teknisellä osaamisella ja muutaman tunnin downtimella sivustosi uudelleen näkyviin (edellytyksellä, että et ole siirtänyt rikkoutunutta uuteen paikkaan). Saat aikaa korjata vanhan. Muutat vain nimitiedot osoittamaan ”peilauspaikkaan” ja olet taas linjoilla.

Lisäosat varmuuskopiointiin

Jos haet WordPressin hallinnan puolella lisäosaa hakusanalla backup, niin saat melkoisesti valinnanvaraa. Lähes kaikki tekevät suunnilleen samaa, mutta niissä on yksi oleellinen ero: mihin pilvipalveluihin ne suostuvat kopiot siirtämään, ja millä hinnalla. Jos lisäosan tekijä pyytää rahaa siitä, että AWS, Dropbox, Google Drive tai OneDrive ovat käytössä, niin älä maksa. Silloin kyse on siitä, että WordPressin repositorya käytetään vain mainostukseen ja perustoiminnallisuus on rampautettu. Yksinkertaisten: sinun pitää maksaa ennen kuin voit kokeilla toimivuutta. Siinä ei ole asiakkaan kannalta mitään järkeä.

Itse käytän UpdraftPlus-lisäosaa. En ole maksanut siitä, koska en ole tarvinnut lisätoiminnallisuuksia, mutta jos tarvitsen (kuten WP CLI -laajennosta), niin minulla ei ole ongelmia pysyä asiakkaana. Ilmaisversio tekee sen mitä lupaa ja lähes täydellisesti – lähes siksi, että aivan kaikki tietokantadumpit eivät ole olleet ehjiä, mutta en tiedä onko se pluginin vai käyttämäni ympäristön vika. Pari kilpailijaa on sen sijaan kämmännyt aikoinaan koko varmuuskopion käyttökelvottomaksi, enkä anna moista virhettä äkkiä anteeksi – ihan sama kuinka ystävällisen valittava tuki heillä on, kun perustuote ei toimi.

UpdraftPlus -lisäosan ilmaisversion käyttämät ”yleiset” pilvipalvelut ovat Dropbox, Google Drive ja Amazon S3. Noilla pärjää käytännössä jokainen.

https://fi.wordpress.org/plugins/updraftplus/

En mene asennusta sen tarkemmin läpi. Se on melkoisen itseäänselittävän helppoa.

Palauttaminen

Yhden asian käytännössä jokainen jättää aina tekemättä: kokeilla miten palauttaminen onnistuu. Ollaan taas ylittämättömän optimistisen positiivisia ja luotetaan, että mitään ei kuitenkaan tapahdu. Samalla onnitellaan omaa itseä siitä, että ollaan ylipäätään asennettu joku varmuuskopiointi.

UpdraftPlus on palautuksessa hyvin yksinkertainen. Valitaan listasta palautettava varmuuskopion, vastataan pariin varmistavaan kysymykseen ja homma on valmis. Ei voisi olla helpompaa.

Paitsi että mitä teet, jos WordPress tarjoaa error 5xx ilmoituksen, etkä pääse hallintaan? Sivuston täydellinen kaatuminen on yleisin seuraus WordPressin epäonnistuneesta päivityksestä ja silloin ei paljoa lohduta lisäosa.

Sinulla on silloin parikin vaihtoehtoa.

• asennat WordPressiin sekä siihen UpdraftPlussan (tai mitä sitten käytätkään) ja sitten teet palautuksen
• siirrät käsin esimerkiksi FTP:llä koko sivuston varmuuskopion takaisin ja jyräät olemassaolevan tietokannan

On kolmaskin tapa. Yritetään korjata se mikä meni rikki edes sen verran, että pääsee sivuston hallintaan.

WordPressin uusasennus ja sitten palautus varmuuskopiosta on aidosti nopein vaihtoehto, jos käytät esimerkiksi DigitalOceanin VPS:ää.

• Teet uuden hakemiston domainille ja uudelleennimeät vanhan joksikin muuksi.
• Asennat WP CLI:llä WordPressin ja lunttaat vanhasta wp-config.php -tiedostosta tarvittavat tiedot, kuten tietokannan käyttäjän ja salasanan
• Asennat UpdraftPlus lisäosan (tai mitä käytätkään) ja teet palautuksen

Aikaa kuluu ehkä 10 minuuttia, jos/kun joudut miettimään mitä teet. Mutta on olemassa vielä helpompikin tapa, joka tosin vaatii hieman teknistä suhtautumista ja mielellään Amazonin AWS:ssä S3-palvelun käyttöä backuppeihin.

Normaalisti linuxpohjaisissa tiedostojen synkkaamiseen ja siirtoon kannattaa käyttää työkalua rsync.  AWS:n kohdalla se ei ole mahdollista, koska Amazon käyttää omanlaistaan systeemiä. Mutta aina kun nixeissä tulee jokin tarve, niin joku propellihattu koodaa työkalun. AWS:n S3 säilöön ja säilöstä saa tiedostoja siirretty rsync:n tapaan useammallakin työkalulla, kuten esimerkiksi:

• aws-cli
• rsync
• duplicity

Siirto kestää hetken ja sen jälkeen ei tarvitse enää kuin siirtää tietokanta paikalleen joko WP CLI:llä tai mysql-komennolla.

Webhotelleissa mahdollisuudet on yleensä rajatummat. Siirrä ensin FTP:llä varmuuskopio omalle koneelle. Poista sillä aikaa esimerkiksi cPanelissa vanha asennus. Kun FTP on ladannut tiedostot omalle koneellesi, niin siirrä sen jälkeen – taas FTP:llä – tiedostot omalta koneelta webhotelliin. Sillä aikaa asennat tietokannan paikoilleen cPanelista löytyvällä phpMyAdmin-ohjelmalla. Aikaa kuluu sivuston koosta riippuen hieman tai niin paljon, että voit käydä vaikka lenkillä tai kaupassa sillä välin. Taas yksi hyvä siirtyä VPS-käyttäjäksi.

Osa palveluntarjoajista tekee backupeja. Tapauksesta riippuen harvakseltaan ilmaiseksi tai useammin maksusta. Ottaen huomioon, että palveluna se ei aidosti maksa hostille mitään, niin erikoishinnoittelu on eräänlaista pakolla rahastamista. Aivan riippuen kuinka usein backup on ajettu, niin siitä on joko hyötyä tai se on katastrofin rajoittamista. Jos sinulla on aktiivinen verkkokauppa, niin 24 tuntia vanha backup on aika turha ja kerran viikossa ajettavat käytännössä turhia.

Suurin ongelma on aika. Jos sivustosi on alhaalla, niin onko sinulla aidosti aikaa odottaa, että tekninen tuki ehtii jossain vaiheessa palauttamaan järjestelmäsi? Entä kun tavallisena webhotelliasiakkaana huomaat, että perjantaina kello 20 sivusto meni rikki, niin aspa vastaa sinulle maanantaina iltapäivällä.

Duplicator Pro

Duplicator Pro on maksullinen lisäosa, joka tekee sivustostasi asennettavan kopion. Vastaavia muitakin on olemassa, useitakin, ja UpdraftPlus tarjoaa vastaavan toiminnallisuuden maksullisessa osassaan.

https://fi.wordpress.org/plugins/duplicator/

Se on yksi harkitsemisen arvoinen työkalu, jos muutat sivustosi muualle. Osassa webhotelleja se jopa toimii, mutta ei se taattua ole – varsinkaan jos palveluntarjoasi kuristaa rajoituksillaan käyttöä. Mutta muutoin se on yksi työkalu lisää varmuuskopiointiinkin koko sivuston osalta.

Jos sinun täytyy asentaa koko systeemi uudestaan, niin siirrät FTP:llä koko sivuston sisältävän paketin paikoilleen, ajat asennusohjelman, päivität toisesta varmuuskopiosta ajantasaisen tietokannan ja olet taas linjoilla.

Käytin sitä yhdessä vaiheessa tekemään viikkobackupin, mutta luovuin siitä. Lähinnä vain siksi, että virtuaaliserverimaailmassa on muitakin työkaluja, ja tuo on aika raskas.

Koko järjestelmä

Webhotelliasiakkaat ovat turvattuja siltä osin, että koko palvelin hajoaa. Korjaus ja palauttaminen vie ajan X eikä sille voi mitään – rehellisyyden nimissä, ei pysty vaikuttamaan VPS-maailmassakaan. Sivuston tiedot palautetaan sille päivämäärälle, jolta palveluntarjoaja on itse ottanut varmuuskopiot. Nämä ovat harvinaisia tilanteita ja voi mennä vuosia, että moinen tulee vastaan. Minulla on ollut niitä jo neljä. Kolme kahdella eri webhotellilla ja yksi VPS-asiakkaana. Jokaisessa tilanteessa olisin selvinnyt melkoiselta työtaakalta (ja suoralta rahankulultakin) jos minulla olisi ollut ajantasaiset varmuuskopiot. Ei ollut.

VPS:llä ollaan enemmän tyhjän päällä. Ihan siksi, että pystyy itsekin rikkomaan paikkoja.

Ubuntussa (ja muissakin pingviineissä) komento rm -rf poistaa mitään kyselemättä hakemiston. Paljon nopeampi kuin FTP-ohjelmien, kuten FileZillan hakemiston deletointi. Olen jyrännyt sillä koko systeemin. Olin juuressa ja aloin kirjoittamaan poistettávan hakemiston polkua malliin rm -rf / kun totesinkin, että menen varmistamaan oikean polun. Minun piti painaa backspacea ja poistaa kirjoittamani, mutta painoin vahingossa enteriä. Se siitä. Ei jäänyt edes savuavia raunioita.

Sillä kertaa minulla oli onneksi tallessa viikon vanha levykuva koko järjestelmästä. Joten palautin sen ja sitten sivustot.

Nykyään moinen koko järjestelmän torpedointi ei enää onnistu. Mutta on muitakin tapoja, kuten muuttaa koko järjestelmän tiedosto-oikeudet. Minä olen tehnyt senkin.

Pointti on yksinkertainen. Varmuuskopiot suojaavat, paitsi teknisiltä ongelmilta, myös omalta kädettömyydeltä ja typeryydeltä.

Webhotellissahan ei voi poistaa kuin oman sivustonsa, joka sekin sattuu. Mutta on helposti palautetettavissa varmuuskopioista. Virtuaaliserverillä voit rikkoa eräällä tavalla koko tietokoneen ja sillä olevat kaikki ohjelmat sekä tiedostot, webbihommissa käytännössä aivan jokaisen sivuston, joka siellä sattuu olemaan. Tämän suhteen VPS häviää webhotelleille. Ei ole nimittäin olemassa sellaista kuin ilmainen varmuuskopio koko järjestelmästä. Se maksaa aina.

Hinta on suurin syy miksi koko systeemin varmuuskopiointia ei tehdä. En tee minäkään, ja se hieman huolestuttaa. Mutta olen vaimentanut epäilyksen äänen sillä, että kun teen mitä tahansa normaalista poikkeavaa, kuten asennan jonkun isomman softan, niin silloin otan ensimmäiseksi levykuvan ja poistan sen noin viikon päästä, jos kaikki toimii hyvin.

Windowsin iso päivitys

Windowsiin tarjotaan uutta major-päivitys ja systeemikin kehottaa päivittämään. Mielellään heti, jos ei aikaisemmin pysty. Kannattaa silti odottaa. Yleensä noin viikossa tai kahdessa tulee seuraava päivytys, joka korjaa ensimmäisen virheet – jokaisen major-päivityksen jälkeen ryhmät täyttyvät avunpyytäjistä, joten riski on olemassa. Toki riski rikkoutumisesta on aina olemassa, mutta se on poikkeuksellisen korkea isoissa päivityksissä.

Jos haluaa olla varovainen, niin odottaa kauemmin. Sen aikaa, että suurin osa – tai edes osa – sinulle tärkeistä lisäosista tarjoavat myös päivitystä. Silloin riski sille, että lisäosa ei enää toimi teeman kanssa, laskee.

Minä teen aina kaksi asiaa ennen isoa päivitystä:

• otan tietokannasta kopion (jos törmäät termiin tietokantadumppi, niin se tarkoittaa samaa)
• kopioin sivuston hakemiston muualle

Minulle se on VPS-asiakkaana kahden komennon ja noin minuutin operaatio.

Jos ja kun sinä olet webhotellissa, niin joudut näkemään hieman enemmän vaivaa, mutta et paljon. Kirjaudu cPaneliin ja etsi sieltä kohta MySQL. Siellä saa tehtyä tietokannasta varmuuskopion. Sitten siirryt tiedostonhallintaana ja kopioit sivustosi hakemiston rinnalle uudella nimellä. Loppuiko tila kesken? Sellaista se on, ja palaat takaisin alkuun selvittämään miten käytät pilvipalveluita hyväksi. Tai otat riskin.

Lopuksi

Se, että ei tee varmuuskopioita. on puhdasta laiskuutta. Ei se ole edes teknistä osaamattomuutta. Jos osaa käyttää WordPressiään, niin osaa käyttää mitä tahansa backup-palikkaa. Jos et tee mitään muuta, niin tee ainakin yksi asia: ota säännöllisesti kopio tietokannasta. Se pelastaa ainakin pahimmalta, kun sivustosi menee rikki. Huomaa: ei jos se menee rikki, vaan kun se menee rikki…

Suunnilleen jokaisella on sama polku oppimisessa. Ensin ei oteta varmuuskopioita ja sitten tulee itku jossain vaiheessa. Sitten otetaan varmuuskopiot, mutta ei osata palauttaa niitä – ja taas tulee itku.

Olen jossain vaiheessa elämääni tehnyt lähiopetuksena WordPressin alkeita aloittelijoille. Ei etäkurssina, vaan vanhan koulukunnan tapaan lähiopetuksena. Pöivön kurssi, ei siihen enempää aikaa tarvita.

Tarjosin serverin, jossa oli cPanel ja opeteltiin alusta asti perustamaan ja rakentamaan sivusto. Tehtiin myös backup-systemiim. Viimeisellä paussilla romautin jokaisen WordPressin ja kun kurssilaiset palasivat tauolta, niin heitä odotti aina yhtä vihattu error 5xx ilmoitus. Sen jälkeen opeteltiin palauttaminen. Se on teoriassa helppoa, mutta käytännössä täytyy tietää mitä tekee ja kun ei tiedäkään, niin ohjeiden hakeminen juuri siinä ja sillä hetkellä on… turhauttavaa.

Jokaisella kurssilla oli aina yksi, joka ei ollut tehnyt varmuuskopioita, koska oli ollut mukavaampaa säätää sivupalkkeja. Jokaisella kurssilla oli aina myös yksi, joka tajusi nopeastikin miten olin sivut kaatanut ja korjasi sivustonsa. Kyllä, sekin on vaihtoehto, ei huono sellainen – silti se palauttaminenkin pitäisi opetella.