Drupal weboldalak mentésének visszaállítása dedikált gépen

Sziasztok,

Adott kb. 70 darab drupal cms-sel készült weboldal ( vegyesen 7.72, 8.9.1, 9.0.1). Ezekről vannak biztonsági mentések, és időnként tesztelni akarom a mentések visszaállítását egy erre dedikált lokális gépen.  Azaz egy gépre kerülne az összes website és ott lehetne tesztelni, hogy sikerült-e a visszaállítás, működik-e minden,stb...  Jelenleg úgy néz ki, hogy manuálisan történik az adatbázisoknak, adatoknak a lemásolása a dedikált gépre. (Elkezdtem scriptet írni, de létezik-e más megoldás esetleg?) Mit javasoltok a folyamat felgyorsítására? Célszerű-e docker-es környezet kialakítása? (verziók miatti különbségek, weboldalak->konténerek). 

Előre is köszi.

Hozzászólások

Backup & migrate-tel biztos lehet automatizálni egy részét a folyamatnak, ezzel szerencsére szinte bármilyen irányba ki tudod exportálni a dolgokat. Extraként drush-sal is kompatibilis, az meg amúgy is segít mindenféle automatizációban.

Alapvetően viszont mivel az általatok készített biztonsági mentések megfelelő visszaállíthatóságát akarod tesztelni, úgy nem biztos, hogy érdemes behozni a képbe még a konténerizációt is. Most inkább az a lényeg, hogy a lokális gép hozza ugyanazokat a paramétereket, mint a prod, hogy minden egyes oldal könnyen felhúzható legyen rá egy fájl+db backupból (persze ha composerrel buildelitek az oldalakat és/vagy más módszerrel operáltok, akkor ez eltérő lesz kissé, de a szisztéma ugyanaz, copypaste, amit csak lehet), amit szigorúan a backupból nyerjetek, és ne egy második másolatot készíts a prodról, mert az nem ugyanaz.

A konténerizáció akkor kerülhet képbe szvsz, amikor a prod környezeted "optimalizálni" szeretnéd (a 70 különböző weboldal már elég érv lehet hozzá), és ha ezzel megvagy, utána innen amúgy is könnyebb lesz majd mind a mentés, mind pedig ezek tesztelésének folyamata, hiszen csak felrántod a konténert, buildelsz, db betölt, files könyvtár bemásol, teszt (vagy valami hasonló).

Gyorsítani a folyamaton millióféleképpen lehet, kezdve attól, hogy cache-t ürítesz a db dumpok létrehozása előtt (külön ügyelve a cache_form-ra), vagy a felesleges táblákat kihagyod (pl. watchdog) egészen addig, hogy S3-ban tárolod a fájlokat, és így nem is kell semmit sehova másolgatni igazából, csak elég a "teszt" site-ok alá a backup bucketet "felcsatolni" vagy éppen külön virt gépeket snapshotolva backupolsz és abból állsz vissza stb. Amúgy a konténerizáció felé történő elmozdulás is természetesen segíthet, mivel így sok időt tudsz megspórolni a prod és teszt env közötti eltérések felesleges keresésével, de ez elég sok kezdeti melóval járhat ennyi oldalt illetően. De érdemes efelé haladni apránként (meg a composeres, buildelős, config export-importos, command line egyszerűen reprodukálható stb. módszerek felé), főleg, ha a site-ok száma idővel csak nőni fog.

Ahha, értem, köszönöm az infókat. :) Jelenleg duplicity ment fájlszinten, db-t pedig automysqlbackup. Megnéztem ezt a backup & migrate-es modult, ez se rossz, de lehet inkább marad így ahogy van a mentések készítése, a visszaállítás meg scriptekkel lesz megoldva egyelőre.