Záloha Docker volume není jen tar: živá databáze může být nekonzistentní

Pojmenované Docker volume zazálohujete tak, že je pomocnému kontejneru připojíte pouze pro čtení a jeho obsah uložíte jako archiv tar.gz do adresáře hostitele. Postup Dockeru pro zálohu a obnovu volume používá dočasný kontejner k vytvoření archivu i k jeho rozbalení.

U živé databáze samotný archiv datových souborů nestačí: před kopírováním zastavte databázový kontejner, nebo za provozu vytvořte databázový dump. Praktický návod Docker HQ upozorňuje, že soubory kopírované během databázových zápisů mohou zachytit různé stavy a při obnově selhat. Výsledek proto vyzkoušejte v novém volume, aniž byste přepsali původní data.

Ověřte název a obsah zdrojového volume

V příkazech níže je app_data ukázkový název pojmenovaného volume a moje-aplikace ukázkový název kontejneru. Nejprve zjistěte, které volume je ke kontejneru skutečně připojeno. V části Mounts výpisu kontejneru porovnejte název volume s cestou, kde aplikace ukládá potřebná data.

docker volume ls

docker inspect moje-aplikace

docker volume inspect app_data

Poslední příkaz musí vypsat existující volume. Při překlepu v názvu uvedeném u docker run totiž Docker může vytvořit nové prázdné volume a pomocný kontejner pak bez zjevné chyby archivuje nesprávný obsah. Zkontrolujte také ovladač volume: ukázkové příkazy předpokládají běžné volume přístupné na daném Docker hostiteli. U síťového nebo jiného zvláštního ovladače ověřte jeho vlastní pravidla pro zálohování.

Ještě před kopírováním rozlište uložené soubory od datového adresáře databáze. Připojení zdroje pouze pro čtení brání změnám ze strany pomocného kontejneru, ale nebrání zápisům aplikace, která používá stejné volume. Pokud musí i sada běžných souborů odpovídat jednomu okamžiku, na dobu archivace zastavte její zápis.

Vytvořte archiv přes pomocný kontejner

Pro volume s běžnými soubory připravte adresář zalohy a spusťte oba příkazy ze stejného pracovního adresáře na Docker hostiteli. Archiv se uloží do tohoto adresáře na hostiteli, nikoli do zdrojového volume.

mkdir -p ./zalohy

docker run --rm -v app_data:/data:ro -v "$(pwd)/zalohy:/backup" alpine tar -czf /backup/app_data.tar.gz -C /data .

Část app_data:/data:ro připojí zdroj do pomocného kontejneru pouze pro čtení. Druhé připojení zpřístupní adresář zalohy jako /backup, kam tar zapisuje výstup; přepínač --rm po dokončení odstraní pomocný kontejner. Závěr příkazu, -C /data ., vloží do archivu obsah volume bez nadřazeného adresáře /data. Při obnově tak soubory skončí přímo v kořeni cílového volume.

Příkaz předpokládá, že se adresář vytvořený pomocí mkdir nachází na hostiteli, na kterém běží Docker Engine. Při práci se vzdáleným Docker hostitelem není místní pracovní adresář automaticky adresářem vzdáleného stroje. Po vytvoření archivu se také ujistěte, že zálohovaná aplikace bude mít po obnově přístup k souborům: práva a číselná ID vlastníků mohou rozhodovat o tom, zda služba data otevře.

Databázi zastavte, nebo použijte její dump

Chcete-li archivovat přímo datové soubory PostgreSQL, nejprve korektně zastavte databázový kontejner a ujistěte se, že do stejného volume nezapisuje další proces. V podmíněném příkladu se kontejner jmenuje postgres-db a jeho volume pgdata; oba názvy před spuštěním nahraďte vlastními. Zálohovací adresář už musí existovat.

docker stop postgres-db

docker run --rm -v pgdata:/data:ro -v "$(pwd)/zalohy:/backup" alpine tar -czf /backup/pgdata.tar.gz -C /data .

docker start postgres-db

Po zastavení zkontrolujte, že kontejner skutečně neběží, a teprve potom spusťte tar. Databázi znovu spusťte i tehdy, když archivace skončí chybou; takový archiv nepovažujte za použitelnou zálohu. Při obnově surového datového adresáře počítejte s verzí PostgreSQL, pro kterou byl vytvořen, a s případnými dalšími umístěními dat používanými danou instalací.

Pokud provoz přerušit nemůžete, použijte logický dump. Dokumentace PostgreSQL k nástroji pg_dump uvádí, že vytváří konzistentní snímek jedné databáze i při souběžném provozu; role a další objekty platné pro celý cluster však do něj nepatří.

docker exec postgres-db pg_dump -U postgres -d appdb -Fc > ./zalohy/appdb.dump

Ukázka předpokládá databázi appdb a uživatele postgres s potřebným přístupem. Přesměrování zapisuje soubor na hostiteli, takže po příkazu zkontrolujte jeho úspěšné dokončení; při selhání může na disku zůstat i neúplný soubor. Formát -Fc se obnovuje nástrojem pg_restore. Pokud potřebujete také další databáze, role nebo soubory aplikace, zahrňte je do stejného plánu zálohy a zkoušky obnovy.

Prověřte soubor a uložte kopii mimo hostitele

U vytvořeného archivu nejprve ověřte, že jej tar dokáže přečíst, a spočítejte kontrolní součet. Příkazy předpokládají nástroj sha256sum na hostiteli. Pro archiv databázového volume nahraďte v názvech souborů app_data za pgdata.

tar -tzf ./zalohy/app_data.tar.gz

sha256sum ./zalohy/app_data.tar.gz > ./zalohy/app_data.tar.gz.sha256

sha256sum -c ./zalohy/app_data.tar.gz.sha256

Výpis tar odhalí některé chyby čtení či komprese; kontrolní součet umožní po přenosu porovnat soubor s uloženou hodnotou. Ani jeden test neprokazuje, že aplikace obnovená data přijme. Archiv i soubor s kontrolním součtem proto uchovejte také mimo původního hostitele a po přenosu kontrolní součet ověřte znovu. Kopie na stejném disku by při jeho ztrátě zmizela spolu s volume.

Obnovu vyzkoušejte v novém volume

Testovací obnovu proveďte pod novým názvem, například app_data_test. Nejdříve příkazem inspect ověřte, že takové volume dosud neexistuje; očekávaným výsledkem je zpráva o nenalezeném volume. To je důležité, protože docker volume create může existující volume se stejným názvem znovu použít.

docker volume inspect app_data_test

docker volume create app_data_test

docker run --rm -v app_data_test:/data -v "$(pwd)/zalohy:/backup:ro" alpine tar -xzf /backup/app_data.tar.gz -C /data

docker run --rm -v app_data_test:/data:ro alpine ls -lan /data

Archiv je při rozbalování připojen pouze pro čtení, zatímco zápis směřuje do nového volume. Výpis potvrdí přítomnost souborů a ukáže číselná ID vlastníků. Pak spusťte odpovídající verzi aplikace nad app_data_test v odděleném testovacím prostředí a ověřte, že potřebná data načte. Testovací službu nepřipojujte současně k produkční databázi ani k původnímu volume.

U archivu zastaveného PostgreSQL postupujte obdobně s novým databázovým volume a izolovanou instancí odpovídající verze. U logického dumpu založte v oddělené testovací instanci prázdnou databázi a načtěte soubor pomocí pg_restore. Zkontrolujte výsledek obnovovacího příkazu, očekávané tabulky a běžný dotaz aplikace; úspěšné vytvoření archivu samo o sobě funkční obnovu neprokazuje.

Přečtěte si také:

• Google Takeout není smazání ani hotová záloha: archiv nejdřív ověřte
• Docker, nebo Podman: výkon nerozhodne, rozdíl je v architektuře
• PostgreSQL, nebo MySQL: jeden benchmark vítěze databáze neurčí