Razendsnel een back up terugzetten vanuit All in One Migration

Een back up terugzetten vanuit All in One Migration hoeft geen eeuw te duren!

De All in One Migration plugin –die ik meerdere malen heb besproken in diverse situaties– is een enorm krachtige plugin voor het maken van een back up, maar deze plugin heeft ook twee grote nadelen.

Het eerste ‘nadeel’ is niet echt een nadeel. Maar gewoon iets wat je mag verwachten van de makers van plugins. Ze willen er geld mee verdienen. En wanneer jouw back up groter is dan een bepaalde grootte (over de jaren is dat steeds minder geworden), dan heb je een extra betaalde add-on nodig. Toch is hier ‘omheen te werken’. Ook wanneer je niet in het bezit bent van een betaalde add on kan je vanuit een All in One Migration ‘WPRESS’ file je back up terug zetten. Het kost je alleen meer werk en tijd. En de vraag is wat in jouw situatie voordeliger is. Die tijd investeren, of éénmalig te investeren in het kopen van een betaalde add-on. Zelf zou ik voor het laatste kiezen. Of eigenlijk… die keuze heb ik jaren geleden al gemaakt.

Een tweede nadeel is dat wanneer je een grote site hebt, het terugzetten van een back up lang kan duren. Want je zal het bestand -soms gigabytes groot- eerst moeten uploaden, voor je een back up terug kan zetten.

En soms overkomt het je, dat tijdens de upload en het uitpakken van dit gigantische bestand je server even een hik krijgt. Niet de schuld van de makers van de plugin, maar wel een probleem wat zo nu en dan de kop opsteekt. En dan moet je weer van voor af aan beginnen.

Dat moet natuurlijk anders kunnen. Maar hoe dan?

Leren begrijpen wat All in One Migration doet…

Voor we kunnen begrijpen hoe we snel een backup terug kunnen zetten vanuit All in One Migration, is het natuurlijk allereest belangrijk te begrijpen, wat deze plugin doet. Het eerste wat je moet begrijpen, is dat All in One Migration meer is dan ‘gewoon’ een plugin voor het maken van back ups. Je kan er namelijk meer mee. En juist vanwege dat ‘meerdere’ gebruik ik de plugin zo graag.

Wanneer je een export maakt, dan wordt er niet zomaar een backup gemaakt van je database, maar wordt ook bijgehouden op wel domein die database was geïnstalleerd. En probeer ik die export terug te zetten op een andere domeinnaam, dan zal All in One Migration iedere keer dat er in de content van de site een verwijzing naar de originele domainnaam voorkomt, deze vervangen door de naam van het nieuwe domein.

Een concreet voorbeeld : Wanneer ik bijvoorbeeld wordxpression.nl zou exporteren met All in One Migration en deze export zou importeren op somesite.wpbizkit.nl dan zou iedere URL die er in de database voorkomt van wordxpression.nl worden aangepast in somesite.wpbizkit.nl. En daar hoef je zelf niets voor te doen.

Naast een kopie maken van de database moet er natuurlijk nog iets gedaan worden. Je hebt bestanden van plugins, thema’s, media en meer die veranderlijk zijn… en dus in een back up meegenomen moeten worden.

Deze bestanden vind je over het algemeen in een folder met de naam wp-content. Wat de All in One Migration plugin dus ook doet, is het kopiëren van die hele wp-content folder.

En al deze bestanden worden ‘ingepakt’ in zo’n WPRESS bestand van All in One Migration.

Helaas is het niet zomaar een ‘zip’ bestand of een bestand in een ander bekend formaat. Het is een compleet eigen formaat. Maar gelukkig bestaan er heel geduldige mensen op aarde, die zomaar de moeite nemen om te onderzoeken hoe zo’n bestand nu precies in elkaar zit.

WPRESS extractor

Al weer heel wat jaartjes geleden (in 2016) heeft Abdullah Irfan heel wat kostbare tijd gestoken in het ontleden van zo’n ‘WPRESS’ bestand. En in de programmeertaal ‘go’ een programma gemaakt wat hij WPRESS extractor noemde. En vandaag de dag werkt dit programma nog steeds prima. Onder Windows.

Want hoewel het Abdullah zijn plan was om een versie te maken die zowel voor de Mac als voor Windows zou werken, geeft Apple het nodige aan het MacOS besturingssysteem aangepast, waardoor het programma niet zal werken onder MacOs.

Helaas Nutella.

WPRESS extract

Wanneer een programmeur eenmaal de oplossing voor een probleem weet, zal het hem weinig moeite kosten dit om te zetten in een willekeurig andere taal. En dat heeft Felix Haus dus gedaan in 2019. In zijn blogartikel bericht hij hier heel uitgebreid over,

Het fraaie van zijn oplossing is dat hij compleet platform onafhankelijk is. Het werkt op Windows, MacOS en zelfs op Linux.

Maar wacht eens… is het belangrijk dat het op Linux werkt? Dat ligt een beetje aan je kennisniveau en de mate van toegang die je tot een server hebt. Maar wanneer je ‘SSH'(Secure Shell) toegang tot je server hebt, dan heb je de mogelijkheid om direct Linux (Unix) commando’s in te geven. En daarmee kan je -wanneer je jouw WPRESS bestand op de server zou laten staan- direct vanaf de server de back up terug kunnen zetten. Waarmee je uren kan besparen. Maar dat is even buiten de scope van dit artikel. We gaan ervan uit, dat je -zoals de meeste mensen met een hosting account- gedwongen bent te werken vanaf een verbonden computer, en niet op de server zelf.

Maar de vraag is natuurlijk… waarom willen we dit bestand uitpakken?

Incremental Restore

Ok, ik moet eerlijk zijn. De term Incremental Restore heb ik zojuist zelf bedacht. Het omgekeerde bestaat echter wel, een incremental back up. Dat komt er eigenlijk op neer, dat we om tijd te besparen, niet iedere keer een complete back up maken, maar alleen een back up van de bestanden die sinds de vorige keer zijn aangepast of toegevoegd.

Daarmee besparen we behoorlijk wat tijd.

Willen we zo’n back up echter terug zetten, dan zullen we eerst de eerste back up terug moeten zetten. Dan de backup met de veranderingen die daarna zijn gemaakt, dan de volgende … enzovoort.

Je begrijpt al, wanneer je zo een back up over tien jaar terug zou willen zetten, ben je bijna een jaar verder voor je klaar bent.

Daarom wordt bij het maken van een incremental back up ook periodiek weer een ‘complete’ backup gemaakt.

Op mijn eigen servers maak ik zo één incremental back up per dag, maar eens in de zeven dagen een complete back up.

Voor mijn webshops doe ik het nog anders. Stel, om 0:00 uur is de backup gemaakt. Een complete. Gedurende de dag wordt ieder uur een incremental back up gemaakt. Ik raak dus bij een storing nooit meer dan één uur gegevens kwijt. Dan wordt het opnieuw 0:00 uur. De volgende dag. Op dat moment wordt een incremental back up gemaakt ten opzichte van de back up van de dag daarvoor. Daarna worden de ‘uur incrementals’ verwijderd, en gaat er een nieuwe serie van 24 incrementals beginnen. Tot 0:00 uur de daarop volgende dag… En na zeven dagen wordt een nieuwe complete back up gemaakt.

Tot zover ons uitstapje naar de incremental back ups, maar hoe zit het nu met een incremental restore?

Het grote nadeel van een incremental back up is dat de restore lang duurt. De incremental restore is juist bedoeld, om het terugzetten van een back up te versnellen.

Een volledige back up incrementeel terug zetten.

Om een ‘incremental’ restore te kunnen doen, heb je een volledige backup nodig. Een tweede ding om rekening mee te houden, is dat wat ik beschrijf een methode is, die zal werken voor WordPress, maar het is beslist geen methode die ook voor andere CMS-en zal werken. Aan de andere kant, WPRESS bestanden kunnen alleen binnen WordPress gemaakt worden, ‘so what’s the point’?

Het eerste wat je zal moeten doen is WPRESS Extractor of WPRESS Extract installeren. En omdat WPRESS Extractor alleen werkt voor Windows gaan we in dit artikel uit van WPRESS Extract. Minus de ‘or’ dus.

Het nadeel hiervan is, dat je gebruik moet maken van Node.Js. Node.Js is eigenlijk bedoeld als een platform voor programmeurs in JavaScript en voor de meeste mensen zal ‘Node.Js’ overkill zijn. Maar gelukkig alleen in schijfruimte.

De voorbereidingen

Wat je zal moeten doen is controleren of Node.Js al is geïnstalleerd. Wanneer jij de enige bent die jouw computer gebruikt en je hebt geen idee wat Node.Js is, wees dan gerust: Het is zeer zeker niet geïnstalleerd.

Op Windows moet je om het te controleren cmd intikken op de zoekregel van Windows. Ik ben geen MacOS gebruiker, maar volgens mij heb je een programma ‘Terminal’ wat je moet gebruiken… als ik het fout heb, vertel het me in de commentaren. En op Linux heb je talloze mogelijkheden om naar de ‘shell’ te gaan, sterk afhankelijk van je distributie. De meeste distributies hebben een command console, en vaak heet die ‘Terminal’.

Om te controleren of je Node.Js geïnstalleerd hebt vraag je eerst de versie van ‘node’ op door het onderstaande commando in te tikken.

node --version

Als Node.JS niet geïnstalleerd is, krijg je de melding, dat ‘node’ een onbekend commando is. Dan zal je het dus eerst moeten installeren.

De vervolgstap is te navigeren naar de plaats waar je jouw WPRESS bestand hebt staan.

Dus je had het al, of je hebt het nu juist geïnstalleerd. Daarna geef je het commando in

npx wpress-extract <naam-van-je-file>.wpress

Het ‘npx’ commando is een node.js commando wat in één stap het programma wpress-extract zal downloaden en uitvoeren. En dat programma heeft een WPRESS bestand nodig, wat daarna uitgepakt zal worden.

Naast je WPRESS bestand komt een folder met dezelfde naam. Wanneer je in die folder kijkt zie je twee dingen.

De inhoud van je /wp-content/ folder

en een bestand daarin met de naam database.sql.

En het allereerste wat je nu gaat doen, is dat bestand database.sql in een compleet andere directory zetten. Want wanneer dat bestand ooit op jouw server zou belanden en iemand zou het bestand daar ontdekken, heeft deze persoon de complete inhoud van je database. Da’s een behoorlijke ‘security breach’ en -afhankelijk van het type van je site- een enorm datalek met betrekking tot persoonsgegevens.

Je hebt dat bestand wel nodig, maar niet op die plaats. Verplaatsen dus.

De volgende stap. De database terugzetten.

Nu gaan we de database terug zetten. Maar voor we dit kunnen doen, moeten we eerst het database.sql bestand aanpassen. Want in WordPress hebben alle tabellen een zogenaamde ‘prefix’. En omdat die prefix tussen twee installaties kan verschillen, zorgt de plugin ervoor, dat zo’n prefix makkelijk te vervangen is. En dat doet hij door een prefix te geven, die je hoogstwaarschijnlijk nooit aan een tabel zou geven.

wp_

Stel nu, dat de prefix van de WordPress tabellen wp_ is. Dat is namelijk de default. Dan moet je eerst met een editor -niet met een tekstverwerker- alle ‘wp_’ prefixen vervangen met ‘wp_’. In Windows kan dit makkelijk met notepad/kladblok. Het laden van het script kan echter even duren en laten lijken dat je computer hangt. Start hem niet opnieuw op!

Daarna sla je het bestand weer op.

phpMyAdmin

Het volgende wat we willen is dit bestand natuurlijk aanbieden aan de database. We willen immers de gegevens vervangen. In vrijwel alle hosting pakketten krijg je een tool aangeboden met de naam ‘phpMyAdmin’. Dit is een behoorlijk krachtige tool, dus ga hier voorzichtig mee om.

Met phpMyAdmin kan je namelijk direct wijzigingen aanbrengen in je database. En het is natuurlijk best belangrijk, dat je dat in de juiste database doet.

Wanneer je maar één WordPress website hebt, en bovendien die éne website geen staging kopieën heeft, dan zal er maar één database zijn, en heb je geen enkel probleem. Maar heb je meerdere databases, is het altijd goed om te controleren of je in de juiste database aan het ‘spitten’ bent. Anders zou je zomaar de gegevens van je éne site door die van een compleet andere vervangen.

In eerste instantie ziet phpMyAdmin er best wel intimiderend uit, wanneer je er niet eerder mee hebt gewerkt. Waar moet je hier nu in vredesnaam op klikken?

Wat goed is, is te realiseren dat je phpMyAdmin gebruikt om meerdere databases te beheren. In ons geval zien we er hier maar één, maar het hadden er net zo goed twintig kunnen zijn. Het eerste wat we dus willen doen, is de database kiezen.

Maar hoe weet je welke je moet hebben?

Dat is eigenlijk makkelijk genoeg. Hiervoor spieken we even in het bestandje wp-config.php op onze server. Daar zie je een drietal regels staan die lijken op het onderstaande :

define('DB_NAME', 'wordpress-123456');

/** MySQL database username */
define('DB_USER', 'wordpress-123456');

/** MySQL database password */
define('DB_PASSWORD', 'mijnsupergeheimewachtwoord');

/** MySQL hostname */
define('DB_HOST', 'localhost');

En we moeten hier hebben wat er achter ‘DB_NAME’ staat. Dat is in ons voorbeeld dus ‘wordpress-123456’. Daar klikken we op en de database wordt geselecteerd.

Nu weten we eigenlijk door de inhoud van het bestand wp-config.php al vrijwel zeker, dat we de goede database hebben. Maar om 100% zeker te zijn, dat we de goede database hebben, klikken we nog eens een keer op een tabel met de naam [prefix]_options. Waarbij ‘prefix’ iedere willekeurige waarde kan zijn, maar in ieder geval de prefix voor jouw database. In het voorbeeld van ons plaatje is dat ‘d7’.

Wanneer we namelijk klikken op deze ‘options’ tabel, dan zien we daar belangrijke informatie staan over onze site… URL.

En hier zien we, dat de URL van de site https://development.wpbizkit.nl is. Als dat de URL is die we verwachtten, kunnen we veilig doorgaan.

Want wat we nu willen is de complete database vervangen door de back up. Om dat te doen moeten we het SQL script wat we hebben uploaden.

Bestand comprimeren

Afhankelijk van de grootte van je site, kan dit SQL bestand behoorlijk groot zijn. Als dat zo is, dan is het goed om het bestand eerste te comprimeren naar een ‘ZIP’ bestand. Dat kan je makkelijk doen vanuit Windows door het bestand in de Explorer aan te klikken en met de rechtermuisknop voor ‘Comprimeren’ te kiezen. Onder Linux werkt het ongeveer hetzelfde, en als je een Mac hebt, weet je hopelijk ook wel hoe het moet. Daar kan ik je niet bij helpen.

Waar je wel even op moet letten, is dat je bestand de juiste naam krijgt. Want MySQL verwacht bij een gecomprimeerd bestand twee extensies. dus iets als database.sql.zip

De .zip geeft hier aan, dat je het bestand met zip hebt gecomprimeerd en niet met bijvoorbeeld G-Zip, want dan was de naam database.sql.gzip heten.

En ‘.sql’ geeft aan, dat het een SQL bestand is, en niet -bijvoorbeeld- een CSV of een XML bestand.

Importeren

Het menu in de bovenbalk is context gevoelig. En omdat we zojuist de ‘options’ tabel hebben aangeklikt zal de knop ‘Importeren’ ons brengen naar een scherm om gegevens in te voeren in de ‘options’ tabel.

Maar dat willen we niet! We willen een complete database vervangen, geen gegevens aan een enkele tabel toevoegen. Dus we zorgen eerst, dat we de goede importeerfunctie kiezen door op ‘Database:’ met daarachter de naam van de database te klikken. Dan krijgen we weer het overzicht van alle tabellen te zien.

Je klinkt nu op ‘Importeren’ en krijgt een scherm als het volgende te zien :

Zoals je ziet, nu gaan we importeren in de database… en niet in een individuele tabel.

We kunnen nu heel veel opties instellen, maar dat hoeven we allemaal lekker niet te doen, omdat we door onze extensies .sql.zip al de belangrijkste zaken hebben verteld, en de rest weet phpMyAdmin zelf uit te zoeken. Het enige wat we dus hoeven te doen, is het bestand selecteren en uploaden. En de database zal worden geïmporteerd, waarbij de oude database wordt overschreven.

Mooi. We hebben nu het eerste deel gedaan. En als het goed is, heeft het lezen van het artikel tot nu toe je meer tijd gekost, dan het daadwerkelijk importeren van de database zelf.

Het uploaden van de bestanden

De volgende stap is het uploaden van de bestanden. Maar niet alle bestanden. We gaan eerst een groot aantal bestanden verwijderen, omdat die helemaal niet geüpload moeten worden.

Je had natuurlijk al het bestand database.sql verplaatst naar een andere plaats. Als je dat niet hebt gedaan, begin dan nog een keer bij het begin van dit artikel en ontdek, waarom het een slecht idee is, om dit bestand zomaar te uploaden.

Maar er zijn meer bestanden die we niet hoeven te uploaden. Allereerst is er waarschijnlijk een folder die /cache/ heet. Die mag je verwijderen. Dit is de folder met de door caching plugins gecachete gegevens. Die bestanden worden straks weer opnieuw aangemaakt door je caching plugin en het is zonde van de tijd te wachten tot deze zijn geüpload.

Tenzij je hele website naar zijn grootje is, en je niets meer hebt, hoef je ook de media folders niet te uploaden. Tenminste niet allemaal.

In de folder /uploads/ zie je een aantal folders met jaartallen. Wanneer er door een software update je site eruit ligt, kan je er aardig zeker van zijn, dat je media nog in orde zijn. Het enige wat je aan media zou kunnen willen uploaden zouden die van de lopende maand zijn.

Verwijder dus alle mappen met een jaartal en klik daarna op de map met de media van het huidige jaar. Verwijder hier alle maanden, behalve de huidige maand.

Dat ruimt op, nietwaar? Samen met de /cache/ folder, zit hier ook de meeste tijdswinst in. In 11 jaar WordXPression heb ik heel wat plaatjes verzameld in mijn /uploads/ folders.

Met deze paar handelingen heb je waarschijnlijk 60-80% van je uploadtijd voor de back up af weten te halen.

Filezilla

Nu hebben we een programma nodig, om de bestanden van onze lokale harde schijf naar de server te verplaatsen. Dat doen we met een FTP programma. En het liefst met FileZilla.

FileZilla is een compleet gratis programma. Er is een betaalde versie (voor het gigantische bedrag van zo’n 20 euro éénmalig), waarmee je ook richting cloud providers als Amazon S3, Microsoft OneDrive en andere kan uploaden, maar voor ons voorbeeld is FileZilla in de gratis versie goed genoeg.

De gebruikersinterface van FileZilla lijkt sterk op die van Windows Verkenner of de MacOS ‘Vinder’, dus hier maak ik niet teveel woorden aan vuil. Links op het scherm vind je de bestanden op je lokale computer, rechts de server.

Nadat je in de server bent ingelogd, de gegevens daarvoor moet je van je host krijgen, kan het zo zijn, dat je nog niet direct op de goede plaats bent. Waar je moet zijn is sterk afhankelijk van de hoster, maar meestal vind je jouw site(s) ergens onder een folder met een naam als public_http, httpdoc, docroot of iets anders met een term ‘doc’ of ‘http(s)’ in de naam.

Klik je daarop kan daaronder nog een structuur zijn, waar de verschillende sites staan. Dus bijvoorbeeld folders met namen als /mijnwebsite1.nl/, /mijnwebsite2.nl/ en meer. En je begrijpt het al, klik je daar weer op, dan kom je binnen de WordPress structuur van je website.

Binnen deze structuur zie je een folder ‘/wp-content/’. En daar dubbelklik je op. Aan de linkerkant van FileZilla zorg je dat je binnen de WordPress structuur staat. Daar zie je dus onder andere een folder ‘/plugins/’, ‘/themes/’ en ‘/uploads/’… Ongeveer hetzelfde wat je aan de rechterkant ziet.

Nu selecteer je links alles en met de rechter muisknop kies je ‘upload’ uit het menu.

En nu wordt alles geupload. Dit kan een tijdje duren.

Enkele notities

Het terugzetten van een back up kost altijd tijd. Je wilt dus graag, dat dit tot een minimum te beperken is. En dat kan je prima doen door risicohandelingen te vermijden op je productiesite. Eén van de meest ‘beruchte’ risicohandelingen is het updaten van je plugins. Sommige mensen doen dit zonder eerst een back up te maken.

Enkele weken geleden nog nam een lezer contact met mij op. Hij had pas WooCommerce geüpdatet maar nam daarbij gelijk de sprong van WooCommerce 3-nogwat naar WooCommerce 5.8.x. Dat was gelijk wel een enorme sprong, en zoals verwacht, ging er van alles verkeerd. Met vereende krachten hebben we binnen vier uur de shop weer online gekregen, maar de lezer (nu klant) had toch heel wat stress kunnen besparen door eerst een back up te maken. Of -nog beter- eerst een vergelijkbare situatie uit te proberen op een staging omgeving.

Een tweede notitie is, dat je met deze methode weinig of geen tijdwinst haalt, wanneer jouw WPRESS bestand kleiner is dan 1 GB. Is je bestand groter dan 2 GB dan kan deze methode je al snel meer dan een uur tijdswinst opleveren bij het terugzetten van je back up.

Blijf bij!

In de blog van WordXPression schrijf ik regelmatig over allerlei onderwerpen. Over e-commerce, e-learning, marketing, maar ook over problemen die jou zomaar kunnen overkomen, op het moment dat je werkt met WordPress… en de oplossing daarvoor.

Eén van de manieren om te voorkomen, dat je straks bij een calamiteit met je handen in het haar zit, is door op voorhand goed geïnformeerd te zijn. Door bijvoorbeeld de blog van WordXPression te lezen. En wanneer je niets wilt missen, kan je je op de nieuwe blogposts abonneren door je in te schrijven op de nieuwsbrief onderaan deze pagina.

Ontvang je liever push berichten in je browser, zodra een nieuw artikel op de site is geplaatst? Dat kan ook. Klik dan op de rode bel links onder aan de pagina en volg de instructies.

Heeft zich al een calamiteit voorgedaan en heb je een helpende hand nodig, dan kan de WordXPression Support Strippenkaart uitkomst brengen.