Zálohy MySQL: mysqldump v cronu, nahrání do S3, test obnovy

Záloha MySQL, na kterou se dá spolehnout, nejsou jedna úloha, ale tři oddělené. První je kopie, která vzniká podle plánu. Druhá je kopie, která leží jinde než databáze. Třetí je pravidelný, nudný důkaz, že se z té druhé kopie dá postavit funkční databáze. Na RE:NODE se první dělá v panelu: plán, který vytváří backup. Druhá a třetí je mysqldump spouštěný z cronu na tvém vlastním stroji, nahrání do S3 storage a skript, který včerejší soubor načte do dočasného MySQL a zkontroluje ho. Tento článek staví všechny tři v pořadí, v jakém mají běžet, a s časy, aby se nepletly jedna druhé do cesty.

Pokud tě zajímají jen přepínače samotného mysqldump, každý vysvětluje mysqldump backup and restore a obecný postup s předáním výpisu do S3 pro tři databázové enginy popisuje database dumps to S3 on a schedule. Tento článek je užší: jedna databáze MySQL, jeden plán a test obnovy, který opravdu budeš dál provozovat.

Plán: tři kopie, tři plány#

Každá vrstva chrání před jinou pohromou a běží v jiný čas, aby se nepřetahovaly o stejnou databázi.

Záloha v panelu je rychlá. Panel RE:NODE drží zálohy ve slotech na každém tarifu, vytváří je na požádání nebo podle plánu, obnovuje je tlačítkem, nechá je stáhnout a nechá zálohu zamknout proti rotaci. Jsou uložené mimo stroj, který chrání. Co nezveřejňujeme, je doba uchování nad rámec rotace, limit velikosti ani to, kde fyzicky leží kopie mimo stroj. Slot proto ber jako pohodlnou první linii, ne jako jedinou kopii. Počet slotů závisí na úrovni tarifu; u MySQL je od jednoho do čtyř, takže si ověř svůj tarif. Smazání serveru maže i jeho zálohy, včetně zamčených, a to je nejsilnější argument pro druhou vrstvu.

Soubor mysqldump je přenosný. Je to obyčejné SQL, takže ho načteš na jiném hostingu, do novějšího MySQL nebo na notebooku. Test obnovy lidé vynechávají nejčastěji, a přitom právě on rozhoduje, jestli ty dvě ostatní vrstvy vůbec platí.

Rozumný rozvrh pro databázi, která je nejklidnější brzy ráno: záloha v panelu ve 03:00, výpis ve 03:30, nahrání hned po něm a test obnovy jednou týdně, v neděli v 06:00. Důležitější než mezery je pořadí. Záloha v panelu i výpis jsou čtenáři, takže se smějí překrývat, ale dlouhý výpis drží otevřený snapshot a dva takové najednou na malém tarifu nechceš.

Kde běží úloha s výpisem#

mysqldump je klient. K databázi se připojuje přes síť jako každá aplikace a nepotřebuje shell na stroji s databází, což je štěstí, protože tarif databáze není místo na instalaci vlastních nástrojů. Na RE:NODE ti server MySQL dá vygenerované heslo roota, databázi aplikace a uživatele aplikace, dostupné na hostu a portu tarifu. Shell na samotném databázovém serveru nepopisujeme, takže počítej s tím, že mysqldump poběží jinde, a podle toho plánuj.

Možnosti pro stroj s úlohou, od nejvhodnější:

• Malý VDS nebo jakýkoli Linuxový stroj, který už provozuješ, s cronem a klientskými nástroji MySQL. To je běžná odpověď.
• Aplikační server, pokud je to stroj, kam můžeš instalovat balíčky a upravovat crontab. Pozor: smazaný aplikační server si s sebou odnese i zálohovací úlohu.
• Tvůj vlastní počítač nebo domácí server, který má tu přednost, že stojí na jiném místě než databáze i bucket.

Karta Schedules v panelu umí na serveru spustit příkaz konzole, backup nebo power action. Pro úlohu backup a pro restarty je to přesně to pravé. Příkaz konzole se zapisuje do konzole serveru, ne do obecného shellu, takže nečekej, že spustí mysqldump proti databázi. Plán v panelu používej na to, co panel umí, a na výpis cron na svém stroji.

Verze klienta by měla odpovídat verzi serveru. Tento článek předpokládá MySQL 8.4 LTS, takže na stroj s úlohou nainstaluj klientské nástroje 8.4. mysqldump mnohem staršího vydání se může zaseknout na přepínačích, které současný server zná, a výpis klientem MariaDB proti MySQL je pro zálohu něco, čemu je lepší se vyhnout. Zjisti, co máš:

$ mysqldump --version$ mysql --version

První krok: plán záloh v panelu#

Otevři server v panelu, přejdi do Schedules a vytvoř plán. Plán má výraz cron a seřazený seznam úloh, z nichž každá může po té předchozí počkat zadanou prodlevu. Pro databázi je užitečný tvar s jednou úlohou, která vytvoří backup. Pokud jsi výraz cron nikdy nepsal, cron expressions explained se čte pět minut.

Denní backup ve 03:00 vypadá takto:

0 3 * * *

Pět polí je minuta, hodina, den v měsíci, měsíc a den v týdnu. Než zvolíš hodinu, zjisti, jaké časové pásmo karta Schedules používá, protože hodiny panelu a hodiny tvého stroje nemusí být tytéž. Pásmo pro plány neuvádíme, takže se podívej, jak karta zobrazuje čas příštího spuštění, a pokud je zobrazení nejasné, vytvoř jeden zkušební plán.

Potom pomysli na sloty. Při jednom až čtyřech slotech na tarifu MySQL denní záloha rychle rotuje. Pomáhají dva zvyky:

1. Druhý, týdenní plán drž jen tehdy, pokud tarifu zbývají sloty, a sloty ber jako krátké okno nedávných stavů, ne jako historii.
2. Zamkni zálohu, kterou chceš zachovat, například tu před rizikovou migrací. Zamčené zálohy jsou z rotace vyňaty, takže pamatuj, že zabírají slot, dokud je neodemkneš.

Spolehlivost zálohy se z panelu nedozvíš. Po prvním spuštění podle plánu otevři Backups a ověř, že se záznam objevil v očekávaný čas a že velikost je věrohodná. Stránka guides prochází kartu Schedules a sekce o zálohách kartu Backups.

Druhý krok: uživatel pro mysqldump#

Úlohu v cronu nespouštěj jako root. Heslo roota je klíč k celému serveru a prostředí cronu je špatné místo, kam ho schovat. Uživatel aplikace, kterého RE:NODE generuje, je lepší volba, protože sahá jen na tvou databázi. Pokud můžeš vytvořit samostatný účet, dej mu jen to, co výpis potřebuje. Pro jednu databázi je to:

CREATE USER 'backup'@'%' IDENTIFIED BY RANDOM PASSWORD;GRANT SELECT, SHOW VIEW, TRIGGER, LOCK TABLES, EVENT ON appdb.* TO 'backup'@'%';

IDENTIFIED BY RANDOM PASSWORD vypíše vygenerované heslo jednou; zkopíruj ho rovnou do souboru s přihlašovacími údaji níže. Zda můžeš na svém tarifu vytvářet další uživatele, zjistíš u svého účtu v panelu, takže to ověř dřív, než na tom začneš stavět; pokud ne, vygenerovaný uživatel aplikace stačí k výpisu vlastní databáze. Pokud --routines selže na oprávnění, MySQL users and privileges vysvětluje oprávnění SHOW_ROUTINE, které to spraví.

Přihlašovací údaje dej do souboru, aby se nikdy neobjevily v seznamu procesů ani v historii shellu:

[client]host = db.example.netport = 30412user = backuppassword = paste-the-generated-password-here

Host a port nahraď těmi, které panel ukazuje pro tvou databázi. Pak soubor zamkni:

$ sudo mkdir -p /etc/backup$ sudo chown root:root /etc/backup && sudo chmod 700 /etc/backup$ sudo chmod 600 /etc/backup/my.cnf

Pokud úloha běží pod běžným uživatelem, nastav vlastníkem adresáře jeho. Smyslem je, aby soubor na stroji s úlohou nemohl číst nikdo jiný. Připojení vyzkoušej, než napíšeš jakýkoli skript:

$ mysql --defaults-extra-file=/etc/backup/my.cnf -e 'SELECT VERSION(), NOW();'

Třetí krok: skript pro výpis#

Rouře mysqldump | gzip > file se přezdívá past: pokud mysqldump umře v polovině, kompresor se přesto čistě dokončí a zanechá malý, na pohled platný soubor. Skript níže se tomu vyhýbá pomocí pipefail, zapisuje pod dočasným jménem a konečné jméno dá až poté, co dokáže, že je soubor úplný. Úplný soubor mysqldump končí řádkem komentáře, který začíná -- Dump completed; v useknutém chybí, takže je to levná a poctivá kontrola úplnosti.

#!/usr/bin/env bashset -euo pipefailDB=appdbWORK=/var/backups/mysqlBUCKET=s3://db-dumps/mysql/$DBPROFILE=storeKEEP_LOCAL_DAYS=3STAMP=$(date -u +%F_%H%M)NAME="$DB-$STAMP.sql.zst"mkdir -p "$WORK"cd "$WORK"mysqldump --defaults-extra-file=/etc/backup/my.cnf \  --single-transaction --routines --events --triggers --hex-blob \  --set-gtid-purged=OFF --no-tablespaces "$DB" \  | zstd -q -T0 > "$NAME.part"zstd -t -q "$NAME.part"zstd -dc "$NAME.part" | tail -n 1 | grep -q '^-- Dump completed'mv "$NAME.part" "$NAME"sha256sum "$NAME" > "$NAME.sha256"aws s3 cp "$NAME" "$BUCKET/$NAME" --profile "$PROFILE" --only-show-errorsaws s3 cp "$NAME.sha256" "$BUCKET/$NAME.sha256" --profile "$PROFILE" --only-show-errorsfind "$WORK" -name "$DB-*.sql.zst*" -mtime +"$KEEP_LOCAL_DAYS" -deleteecho "ok $NAME $(stat -c %s "$NAME") bytes"

Projdi si, co dělá, protože každý řádek má svůj důvod:

• set -euo pipefail zastaví skript při první chybě, u nenastavené proměnné a při selhání kteréhokoli článku roury. Bez pipefail by byl návratový kód roury výpisu kód kompresoru.
• --single-transaction čte všechny tabulky InnoDB z jednoho konzistentního snapshotu a neblokuje zapisovatele. --routines --events --triggers dají do souboru uložené procedury, plánované události a triggery. --hex-blob bezpečně zapisuje binární sloupce. --set-gtid-purged=OFF a --no-tablespaces obejdou dvě chyby, které nejčastěji zastaví výpis pořízený běžným uživatelem.
• zstd -t testuje integritu komprimovaného souboru. Další řádek ho rozbalí a zkontroluje poslední řádek, což dokazuje, že samotný výpis skončil normálně, a ne jen že komprese zůstala neporušená.
• Jméno .part znamená, že napůl zapsaný soubor nikdy nesplete se zálohou. Konečné jméno dostane jen soubor, který prošel oběma kontrolami.
• Kontrolní součet se nahrává vedle výpisu. Test obnovy ho použije k odhalení poškozeného stažení nebo nahrání, které se nepovedlo.
• Místní kopie se po třech dnech mažou. Dlouhou historii drží bucket; stroj s úlohou potřebuje jen posledních pár pro rychlou obnovu.

Nainstaluj nástroje a soubor udělej spustitelný. Názvy balíčků níže platí pro Debian a Ubuntu:

$ sudo apt install mysql-client zstd awscli$ sudo chmod 755 /usr/local/bin/mysql-backup.sh$ sudo /usr/local/bin/mysql-backup.sh

Jednou ho spusť ručně a přečti si výstup, než ho naplánuješ. Poznamenej si velikost souboru a jak dlouho to trvalo. Obě čísla jsou tvůj výchozí stav.

Čtvrtý krok: úložiště S3 jako kopie mimo server#

Nahrávání používá AWS CLI, protože je na každé platformě a S3 storage RE:NODE s ním funguje. Každý server S3 přichází s vygenerovaným access key a secret key a s už vytvořeným prvním bucketem, s adresováním path-style a libovolným názvem regionu. Endpoint mluví obyčejným HTTP na svém portu a HTTPS vede přes proxy slot tarifu. Pro databázový výpis z toho plyne praktický důsledek: soubor putuje po síti, takže buď použij adresu HTTPS, nebo soubor zašifruj dřív, než stroj s úlohou opustí. Výpis obsahuje všechny uživatele, všechny hashe a všechny adresy tvé aplikace.

Profil na stroji s úlohou nastav jednou. Endpoint níže je zástupný text za adresu, kterou ukazuje tvůj tarif:

[profile store]region = us-east-1endpoint_url = https://s3.example.comrequest_checksum_calculation = when_requiredresponse_checksum_validation = when_requireds3 =  addressing_style = path

[store]aws_access_key_id = YOUR_ACCESS_KEYaws_secret_access_key = YOUR_SECRET_KEY

Vyzkoušej to výpisem. První volání hlasitě selže, pokud je špatně endpoint, klíče nebo styl adresování:

$ aws s3 ls s3://db-dumps/ --profile store

S3 storage with the AWS CLI rozebírá endpoint a nastavení checksum podrobněji. Pokud dáváš přednost rclone, odpovídající remote je v rclone with S3 storage.

K šifrování je nejlevnější vložit age mezi kompresor a soubor: konec řádku s výpisem změň na | zstd -q -T0 | age -r YOUR_PUBLIC_KEY > "$NAME.part" a uprav jméno a kontroly, což znamená, že kontrola úplnosti musí nejdřív dešifrovat, soukromým klíčem, který bys na stroji s úlohou neměl nechávat. Právě kvůli tomuto napětí si mnoho lidí v první verzi vybere HTTPS a uzamčený bucket a šifrování přidá později. Ať zvolíš cokoli, dešifrovací klíč ulož tam, kde přežije ztrátu stroje s úlohou.

Tarif S3 storage drží jednu kopii na NVMe na jednom místě, bez replikace. Je to druhý domov pro výpisy, ne třetí. Pokud na datech záleží, platí myšlenka 3-2-1 z S3 storage sizing and the 3-2-1 rule: záloha v panelu, výpis v bucketu a občasné stažení někam úplně jinam. Velikost bucketu odvoď z pravidel uchování. Třicet denních výpisů po 300 MB komprimovaných dělá asi 9 GB, což se na tarif s 10 GB sotva vejde, takže před výběrem tarifu změř svůj první soubor.

Pátý krok: naplánuj to v cronu#

Cron je plánovač na stroji s úlohou. Uprav crontab uživatele, kterému patří přihlašovací údaje:

$ crontab -e

MAILTO=you@example.com30 3 * * * flock -n /tmp/mysql-backup.lock /usr/local/bin/mysql-backup.sh >> /var/log/mysql-backup.log 2>&1

Do MAILTO doplň svou adresu; cron e-mailem posílá výstup úlohy, který nikam nepřesměruješ, i když tady ho přebírá log. 30 3 * * * je každý den 03:30 v časovém pásmu stroje s úlohou, které zjistíš příkazem timedatectl. flock -n odmítne spustit druhou kopii, pokud předchozí ještě běží, což je na rostoucí databázi cesta, jak vzniknou dva překrývající se výpisy. Log musí existovat a být zapisovatelný pro uživatele úlohy:

$ sudo touch /var/log/mysql-backup.log$ sudo chown "$USER" /var/log/mysql-backup.log

Cron běží s minimálním PATH, takže skript, který funguje v tvém shellu a z cronu selže, skoro vždy nenajde aws nebo zstd. Buď spusť command -v aws zstd mysqldump a adresáře vlož do řádku PATH= na začátek crontabu, nebo v skriptu používej úplné cesty. Log zkontroluj ráno po prvním spuštění, ne za týden.

Úloha, která přestala běžet, vypadá úplně stejně jako úloha, která funguje, takže přidej poplach na ticho. Mnoho bezplatných monitorovacích služeb ti dá URL; skript na ni zavolá jen na konci úspěšného běhu a ty dostaneš upozornění, když volání chybí. Přidej jeden řádek jako poslední příkaz skriptu:

curl -fsS -m 10 --retry 3 "https://hc.example.com/ping/your-uuid" > /dev/null

Sleduj také řádek s velikostí, který skript zapisuje do logu. Výpis, který náhle klesne na pár kilobajtů, selhal způsobem, který návratové kódy nezachytily, například proto, že uživatel aplikace přišel o oprávnění.

Šestý krok: test obnovy#

Záloha, kterou nikdo neobnovil, je hypotéza. Test obnovy z ní dělá fakt a vyplatí se ho zautomatizovat, protože ruční verze se stane jen jednou. Myšlenka je jednoduchá: stáhnout z bucketu nejnovější výpis, zkontrolovat kontrolní součet, načíst ho do dočasného MySQL stejné verze, který existuje jen pro test, spustit pár dotazů, které uspějí jen nad skutečnými daty, vypsat, jak dlouho to trvalo, a všechno smazat.

Docker je nejsnazší dočasný server a drží test dál od tvé skutečné databáze. Připni stejnou verzi jako server, tady 8.4:

#!/usr/bin/env bashset -euo pipefailDB=appdbBUCKET=s3://db-dumps/mysql/$DBPROFILE=storeCTR=restore-test-$$EXPECT_TABLES=12WORK=$(mktemp -d)cleanup() { docker rm -f "$CTR" > /dev/null 2>&1 || true; rm -rf "$WORK"; }trap cleanup EXITcd "$WORK"LATEST=$(aws s3 ls "$BUCKET/" --profile "$PROFILE" \  | awk '{print $4}' | grep '\.sql\.zst$' | sort | tail -n 1)[ -n "$LATEST" ] || { echo "no dump found"; exit 1; }aws s3 cp "$BUCKET/$LATEST" . --profile "$PROFILE" --only-show-errorsaws s3 cp "$BUCKET/$LATEST.sha256" . --profile "$PROFILE" --only-show-errorssha256sum -c "$LATEST.sha256"docker run -d --name "$CTR" -e MYSQL_ROOT_PASSWORD=scratch \  -e MYSQL_DATABASE="$DB" mysql:8.4 > /dev/nulluntil docker exec "$CTR" mysql -h127.0.0.1 -uroot -pscratch -e 'SELECT 1' \    > /dev/null 2>&1; do sleep 2; doneSTART=$(date +%s)zstd -dc "$LATEST" | docker exec -i "$CTR" mysql -uroot -pscratch "$DB"END=$(date +%s)TABLES=$(docker exec "$CTR" mysql -uroot -pscratch -N -e \  "SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='$DB'")echo "tables: $TABLES (expected at least $EXPECT_TABLES)"[ "$TABLES" -ge "$EXPECT_TABLES" ]docker exec "$CTR" mysql -uroot -pscratch -N "$DB" -e \  "SELECT COUNT(*) AS orders, MAX(created_at) AS newest FROM orders"echo "restored $LATEST in $((END - START)) s"

Záleží na několika detailech. Oficiální image MySQL při inicializaci spustí dočasný server a pak se restartuje. Ten dočasný server nenaslouchá na TCP, proto se čekací smyčka připojuje přes -h127.0.0.1 a projde, až když naběhne skutečný server; prosté mysqladmin ping přes socket může uspět příliš brzy a import pak narazí na restart. EXPECT_TABLES je číslo, které nastavuješ ručně, počet tabulek, které by tvá databáze měla mít, a test selže, pokud jich obnovená kopie má méně. Poslední dotaz je ten, který přizpůsob: vezmi libovolnou tabulku a sloupec s časem, který tvá aplikace zapisuje při každé změně, abys na první pohled viděl, že nejnovější řádek je z včerejška a ne z minulého měsíce.

trap odstraní kontejner i dočasný adresář bez ohledu na to, zda test prošel, nebo selhal, takže selhání nezanechá nic. Jednorázové heslo roota scratch je neškodné, protože kontejner nezveřejňuje žádný port.

Poprvé ho spusť ručně a přečti si, co říká. Pak ho dej do cronu jednou týdně, mimo okno výpisu:

0 6 * * 0 /usr/local/bin/mysql-restore-test.sh >> /var/log/mysql-restore-test.log 2>&1

Číslo, které stojí za to si z prvního běhu uložit, je doba obnovy. Výpis o několika stovkách megabajtů se na notebooku načte za minuty, ale načítání znovu staví všechny indexy a obnova bývá několikrát pomalejší, než byl výpis. Pokud je to číslo větší než výpadek, který snesete, odpověď není rychlejší skript, ale paralelní výpis a načtení pomocí MySQL Shell, popsané v mysqldump backup and restore, nebo menší databáze. Test a backup restore: a 30-minute drill mění stejnou myšlenku v rutinu pro tým.

Obnova doopravdy#

Až ten den přijde, máš dvě cesty a rychlejší vybere panel. Pro chybu z posledních pár dní zkus jako první slot backup: obnov ho tlačítkem na kartě Backups. Než ho stiskneš, pamatuj, že obnova nahrazuje současný stav, takže pokud databáze obsahuje změny, které chceš zachovat, nejdřív pořiď čerstvý backup nebo stáhni slot, přes který se chystáš obnovovat.

Když slot už není nebo není server, použij výpis. Na novém serveru vytvoř databázi a soubor načti rovnou z bucketu:

$ aws s3 cp s3://db-dumps/mysql/appdb/appdb-2026-10-23_0330.sql.zst - --profile store \    | zstd -dc \    | mysql --defaults-extra-file=/etc/backup/my.cnf appdb

Obnovuj do prázdné databáze. Výpis zahodí a znovu vytvoří tabulky, které obsahuje, ale ostatní tabulky nechá být, takže načtení „přes“ živou databázi dá směs. Pokud aplikace nemá vidět napůl načtenou databázi, obnov do databáze s novým jménem a connection string přepni, až bude všechno kompletní. Pokud se stěhuješ na úplně jiný hosting, migrating MySQL to a new host pokrývá uživatele, definery a přepnutí.

Co se pokazí#

Selhání se shlukují kolem několika příčin a většina je tichá.

• Úloha nikdy neběžela. Cron má minimální PATH, crontab patří jinému uživateli nebo byl stroj postaven znovu. Chybějící zavolání monitorovací služby je způsob, jak to zjistíš do jednoho dne. Bez něj to zjistíš při obnově.
• Access denied pro tablespaces. Od MySQL 8.0.21 vyžaduje výpis informací o tablespace globální oprávnění PROCESS. Skript předává --no-tablespaces, což výpis aplikace potřebuje.
• Výpis je maličký. Uživatel se připojí, ale nic nevidí, nebo je špatně jméno databáze. mysqldump může na prázdné databázi skončit úspěšně. V logu si drž řádek s velikostí a porovnávej ho s včerejškem.
• Chybí `Dump completed`. Spojení se uprostřed výpisu přerušilo, obvykle při dlouhém běhu na nespolehlivém spoji. Skript takový soubor nepovýší a ty vidíš chybu v logu a v bucketu žádný nový objekt.
• Nahrání selže s chybou checksum nebo adresování. Dvě nastavení checksum v profilu a addressing_style = path jsou obvyklá oprava pro endpointy kompatibilní s S3.
• Obnova je špatně tak, že to žádná kontrola nezachytí. Počty řádků sedí a nejnovější časové razítko je správné, ale chybí uložená procedura. To jsou --routines a --events vynechané z příkazu výpisu, a proto je skript má.
• Výpis se kryje s migrací. --single-transaction nechrání před změnami schématu uprostřed výpisu. Nenasazuj migrace mezi 03:25 a dobou, kdy výpis obvykle končí.

Pokud je databáze malá, celá rutina spotřebuje každou noc pár stovek megabajtů úložiště a pár minut času stroje s úlohou. Pokud je velká, nad čím budeš přemýšlet, je doba obnovy, a správná chvíle to zjistit je nedělní test, ne výpadek.

FAQ#

Mohu spustit mysqldump z karty Schedules v panelu?

Jako způsob výpisu databáze ne. Plán na serveru spouští příkaz konzole, backup nebo power action a příkaz konzole jde do konzole serveru, ne do obecného shellu. Plán používej pro zálohy a restarty a mysqldump spouštěj z cronu na samostatném stroji.

Kolik záloh v panelu mám držet?

Tolik, kolik dovolují sloty tvého tarifu, a ber je jako krátké okno nedávných stavů. Tarif MySQL má podle úrovně jeden až čtyři sloty. Před rizikovou změnou zamkni ten, o který nesmíš přijít, a dlouhou historii drž jako výpisy v S3.

Jak často mám spouštět test obnovy?

U důležité databáze je dobrým výchozím nastavením jednou týdně a také po každé změně skriptu s výpisem, verze MySQL nebo přihlašovacích údajů. Test stojí pár minut náhradního stroje a první selhání, které zachytí, zaplatí všechna spuštění bez incidentu.

Mám výpisy šifrovat?

Ano, pokud soubor putuje po síti bez HTTPS nebo by mohly uniknout klíče k bucketu, protože výpis obsahuje všechny uživatele a hashe v databázi. Endpoint S3 mluví na svém portu obyčejným HTTP, takže použij adresu HTTPS za proxy slotem tarifu, nebo před nahráním šifruj nástrojem jako age a klíč ulož odděleně od stroje s úlohou.

Co když je databáze na jeden soubor mysqldump příliš velká?

Zhruba od 20 až 50 GB se jednovláknový výpis a hlavně jednovláknová obnova zpomalí. Nástroje dump a load z MySQL Shell pracují paralelně a bývají dalším krokem. Nejdřív změř dobu obnovy, protože právě to číslo rozhoduje, jestli vůbec musíš něco měnit.