მონაცემთა ბაზის dump-ები S3-ში განრიგით: Postgres, MySQL, MongoDB

მონაცემთა ბაზის ღამის dump S3-ში არის cron-ის ერთი ხაზი, რომელიც dump-ის ხელსაწყოს გამოსავალს ატვირთვაში გადასცემს: pg_dump -Fc | aws s3 cp - s3://db-dumps/app/$(date +%F).dump. ეს ხაზი მუშაობს, მაგრამ ის ასევე შეიცავს იმ ყველაზე გავრცელებულ გზას, რომლითაც ასეთი დავალებები ჩუმად მარცხდება - როცა dump შუა გზაზე კვდება, ატვირთვა მაინც წარმატებით სრულდება და ყოველ ღამე ინახავ მოჭრილ ფაილს, იმ დღემდე, სანამ ერთი მათგანი არ დაგჭირდება. ეს პოსტი დავალებას სწორად აწყობს PostgreSQL-ისთვის, MySQL-ისთვის და MongoDB-ისთვის: სად გაუშვა, როგორ დამალო პაროლები პროცესების სიიდან, როგორ დარწმუნდე, რომ მხოლოდ სრული dump-ები ინახება, დაშიფვრა, შენახვის ვადა lifecycle-ის წესების გარეშე და აღდგენის ტესტი, რომელიც გეტყვის, მუშაობს თუ არა ამათგან რამე.

სად ეშვება დავალება#

dump-ის ხელსაწყო მონაცემთა ბაზას ნებისმიერი კლიენტივით უკავშირდება, ამიტომ დავალება შეიძლება გაეშვას ნებისმიერ მანქანაზე, რომელიც ბაზის ჰოსტსა და პორტს წვდება და რომელზეც საჭირო კლიენტის ხელსაწყოებია დაყენებული. ვარიანტები, დაახლოებით უპირატესობის მიხედვით:

• პატარა Linux VDS ან სერვერი, რომელიც უკვე გაქვს, cron-ით და კლიენტის პაკეტებით. ჩვეულებრივი პასუხი.
• აპლიკაციის სერვერი, თუ ის სრული მანქანაა, სადაც შეგიძლია postgresql-client დააყენო და cron-ის დავალება დაამატო.
• შენი კომპიუტერი ან სახლის სერვერი, რომლის უპირატესობაც ის არის, რომ ის სხვა ადგილასაა, ვიდრე მონაცემთა ბაზაც და bucket-იც.

მართვადი მონაცემთა ბაზის ხაზები ხშირად თავად ბაზის მანქანაზე shell-ს არ გაძლევს, და ეს ნორმალურია: ქსელით dump-ის აღება ჩვეულებრივი გზაა. RE:NODE-ზე PostgreSQL-ის, MySQL-ის და MongoDB-ის ხაზებს გეგმის ჰოსტითა და პორტით, გენერირებული ავტორიზაციის მონაცემებით უკავშირდები, და მათ საკუთარი პანელის backup-ის სლოტები აქვთ. ისინი სწრაფი უკან დაბრუნებისთვის გამოიყენე; S3-ში dump არის ასლი, რომელიც წაშლილ სერვერს გადაურჩება და გაძლევს გადატანად ფაილს, რომლის ჩატვირთვაც ნებისმიერ ადგილას შეგიძლია.

კლიენტის ვერსიას მნიშვნელობა აქვს. pg_dump უნდა იყოს სერვერის იგივე მთავარი ვერსიის ან უფრო ახალი - ძველი pg_dump უფრო ახალი სერვერის dump-ზე უარს ამბობს. MySQL 8.4-ის mysqldump 8.4 სერვერს სუფთად იღებს; MariaDB-ის mysqldump MySQL 8.4-ის წინააღმდეგ ძირითადად მუშაობს, მაგრამ backup-ისთვის სანდო ხელსაწყო არ არის. mongodump მოდის MongoDB Database Tools პაკეტიდან, რომელსაც სერვერისგან დამოუკიდებელი ვერსიები აქვს; ნებისმიერი ბოლოდროინდელი რელიზი მიმდინარე სერვერებს უჭერს მხარს.

ავტორიზაციის მონაცემები გაჟონვის გარეშე#

ბრძანების ხაზზე გადაცემული პაროლები ps-ით მანქანის ყველა მომხმარებლისთვის ჩანს და shell-ის ისტორიაში ხვდება. თითოეულ ხელსაწყოს ფაილზე დაფუძნებული ალტერნატივა აქვს.

[client]host = db.example.netport = 3306user = backuppassword = s3cret-generated-value

--defaults-extra-file ბრძანების ხაზზე პირველი პარამეტრი უნდა იყოს, თორემ mysqldump მას უგულებელყოფს. თითოეული ეს ფაილი წაკითხვადი გახადე მხოლოდ იმ მომხმარებლისთვის, რომლითაც დავალება ეშვება (chmod 600).

სადაც შეგიძლია, dump-ს საკუთარი მონაცემთა ბაზის მომხმარებელი მიეცი. backup-ის მომხმარებელს წაკითხვის წვდომა სჭირდება და არა ჩაწერის: PostgreSQL-ში ეს არის pg_read_all_data როლი (PostgreSQL 14 და უფრო ახალი); MySQL-ში - SELECT, SHOW VIEW, TRIGGER, EVENT და LOCK TABLES ბაზაზე, პლუს PROCESS გლობალურად, რომ tablespace-ების შესახებ გაფრთხილება აირიდო. ასე გაჟონილი backup-ის მონაცემებით ვერაფერს შეცვლიან. PostgreSQL-ის როლები და უფლებები Postgres-ის დეტალებს შეიცავს.

bucket-ის მხარისთვის ერთხელ დააყენე AWS CLI-ის პროფილი endpoint-ით, path-style მისამართებით და checksum-ის თავსებადობის პარამეტრებით, როგორც აღწერილია სტატიაში S3 საცავი AWS CLI-ით:

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

PostgreSQL#

გამოიყენე custom ფორმატი (-Fc). ის შეკუმშულია, და pg_restore-ს შეუძლია მისგან ერთი ცხრილის ან სქემის აღდგენა, მისი შიგთავსის ჩამოთვლა და პარალელური აღდგენა. ჩვეულებრივი SQL dump-ის გაშვება მხოლოდ მთლიანად შეიძლება.

$ pg_dump -h db.example.net -p 5432 -U backup -d app -Fc --no-owner \    | aws s3 cp - "s3://db-dumps/pg/app/$(date -u +%F_%H%M).dump" --profile store

pg_dump თანმიმდევრულ snapshot-ს ერთი ტრანზაქციის შიგნით იღებს, ამიტომ dump ერთ მომენტს ასახავს, მაშინაც კი, როცა აპლიკაცია წერას აგრძელებს. ის ჩამწერებს არ ბლოკავს. --no-owner მფლობელობის ბრძანებებს გამოტოვებს, რაც ფაილს აღდგენადს ხდის ბაზაში, რომლის მომხმარებელსაც სხვა სახელი აქვს - სასარგებლოა, როცა აღდგენის სამიზნე ახალი სერვერია გენერირებული მონაცემებით. როლები და კლასტერის დონის სხვა ობიექტები pg_dump-ის ფაილში საერთოდ არ არის; თუ ისინი გჭირდება, pg_dumpall --globals-only მათ იღებს, თუმცა მართვად ხაზზე ერთ აპლიკაციის მომხმარებელს ჩვეულებრივ ხელით ქმნი თავიდან. pg_dump და pg_restore ყველა ფლაგს განიხილავს.

MySQL#

$ mysqldump --defaults-extra-file=/etc/backup/my.cnf \    --single-transaction --routines --triggers --events --hex-blob \    --set-gtid-purged=OFF app \    | zstd -q -T0 \    | aws s3 cp - "s3://db-dumps/mysql/app/$(date -u +%F_%H%M).sql.zst" --profile store

რისთვისაა თითოეული ფლაგი:

• --single-transaction InnoDB ცხრილებს ერთი თანმიმდევრული snapshot-იდან იღებს, მათი ჩაკეტვის გარეშე. MyISAM ცხრილებზე არაფერს აკეთებს, რომლებიც ჩაკეტვის გარეშე თანმიმდევრული არ არის - კიდევ ერთი მიზეზი, რომ საერთოდ არ გქონდეს.
• --routines --triggers --events შეიცავს stored procedure-ებს, trigger-ებს და დაგეგმილ event-ებს. trigger-ები ნაგულისხმევად ჩართულია; დანარჩენი ორი - არა, და dump მათ გარეშე აღადგენს ბაზას, რომელსაც ჩუმად აკლია ლოგიკა.
• --hex-blob ბინარულ სვეტებს hex-ად წერს, რაც უკან ჩატვირთვისას სიმბოლოების კოდირების ნებისმიერ შეცდომას უძლებს.
• --set-gtid-purged=OFF GTID-ის ბრძანებებს dump-ის გარეთ ტოვებს, რომ ის იმპორტირდეს სერვერზე, რომელიც იმავე რეპლიკაციის სისტემის ნაწილი არ არის.

გაითვალისწინე, რომ mysqlpump, პარალელური ალტერნატივა, რომელსაც ზოგი ძველი გზამკვლევი გირჩევს, MySQL 8.4-ში წაიშალა. mysqldump რჩება, ხოლო რამდენიმე გიგაბაიტზე დიდი ნებისმიერი რამისთვის MySQL Shell-ის dump-ის უტილიტები უფრო სწრაფია. mysqldump-ით backup და აღდგენა აღდგენას და დიდ dump-ებს განიხილავს.

MongoDB#

$ mongodump --config=/etc/backup/mongo.yaml --archive --gzip \    | aws s3 cp - "s3://db-dumps/mongo/app/$(date -u +%F_%H%M).archive.gz" --profile store

uri: mongodb://backup@db.example.net:27017/app?authSource=adminpassword: s3cret-generated-value

--archive ფაილის სახელის გარეშე stdout-ში ერთ არქივის სტრიმს წერს, --gzip კი მას კუმშავს. აღდგენა იმავე სტრიმს კითხულობს: aws s3 cp s3://... - | mongorestore --archive --gzip --drop. ცალკე მდგომ სერვერზე mongodump არ არის snapshot ერთი მომენტისთვის - ხანგრძლივი dump-ის დროს ჩაწერილი დოკუმენტები შეიძლება მოხვდეს ან არ მოხვდეს მასში. --oplog ამას ასწორებს, მაგრამ მხოლოდ replica set-ზე მუშაობს. პატარა აპლიკაციების უმეტესობისთვის ყველაზე მშვიდ საათში აღებული dump საკმარისად თანმიმდევრულია; თუ შენი ასეთი არ არის, შეაჩერე ჩაწერა ან dump replica-დან აიღე. mongodump და mongorestore დანარჩენს შეიცავს.

Valkey და SQL Server

ორ სხვა ძრავას განსხვავებული მიდგომა სჭირდება. Valkey მონაცემებს მეხსიერებაში ინახავს და დისკზე თავად წერს, ამიტომ "dump" მისი snapshot-ის ასლია. valkey-cli-ს (ან redis-cli-ს, რომელიც იმავე პროტოკოლზე საუბრობს) შეუძლია ის ქსელით მოიტანოს: valkey-cli -h db.example.net -p 6379 --user default --pass "$PW" --rdb /tmp/dump.rdb სერვერს ახალ RDB ფაილს სთხოვს და ლოკალურად წერს, ატვირთვისთვის მზად. ხალხის უმეტესობა cache-ის backup-ს საერთოდ არ აკეთებს - თუ ის რეალური ბაზიდან თავიდან აიგება, მისი დაკარგვა რამდენიმე ნელ წუთად ჯდება - მაგრამ Valkey, რომელიც სესიებს ან რიგებს ინახავს, ღამის ასლად ღირს. ბრძანების ხაზზე --pass ps-ში ჩანს; redis-cli პაროლს ამის ნაცვლად REDISCLI_AUTH გარემოს ცვლადიდან კითხულობს, valkey-cli --help კი გაჩვენებს, რომელ ცვლადს ითვალისწინებს შენი ვერსია.

SQL Server პირიქით მუშაობს: BACKUP DATABASE .bak ფაილს სერვერის საკუთარ დისკზე წერს, Express-ს კი SQL Server Agent არ აქვს მის დასაგეგმად. ჩვეულებრივი ნიმუშია sqlcmd-ის დაგეგმილი გამოძახება სხვა მანქანიდან backup-ის გასაშვებად, შემდეგ კი ფაილის მოტანა. SQL Server-ის backup და აღდგენა ამას განიხილავს, ბოლოს ატვირთვის ნაბიჯი კი იგივე aws s3 cp-ია, რაც ყველგან.

pipe, რომელიც dump-ის ნახევარს ტვირთავს#

აი შესავლის ხაფანგი დეტალურად. pipeline-ში A | B shell B-ს გასვლის სტატუსს აბრუნებს. თუ pg_dump 1 GB-იანი dump-ის 300 MB-ის შემდეგ კავშირს კარგავს, ის შეცდომით გადის, pipe იხურება, aws s3 cp - ხედავს შეყვანის ნორმალურ დასასრულს, ტვირთავს 300 MB-ს და 0-ით გადის. დავალება "წარმატებით შესრულდა". შეიძლება ყოველ ღამე ასე "სრულდებოდეს".

set -o pipefail სკრიპტს ამის შემჩნევას აიძულებს - pipeline ახლა მარცხდება, თუ რომელიმე ეტაპი ჩავარდა - მაგრამ მოჭრილი ობიექტი უკვე bucket-შია, და მის სახელში არაფერი ამბობს ამას. ორი საიმედო ნიმუში:

ატვირთე დროებით გასაღებზე, წარმატების შემთხვევაში გადაიტანე.

TMP="s3://db-dumps/_incoming/app-$$.dump"FINAL="s3://db-dumps/pg/app/$(date -u +%F_%H%M).dump"if pg_dump ... -Fc | aws s3 cp - "$TMP" --profile store; then  aws s3 mv "$TMP" "$FINAL" --profile storeelse  aws s3 rm "$TMP" --profile store  exit 1fi

როცა pipefail დაყენებულია, if ნებისმიერი ეტაპის ჩავარდნას ხედავს. ჩავარდნილი გაშვება საბოლოო prefix-ის ქვეშ არაფერს ტოვებს, _incoming/-ში გაჭედილი ნებისმიერი რამ კი პრობლემის თვალსაჩინო ნიშანია. mv არის სერვერის მხარეს კოპირება, რომელსაც წაშლა მოსდევს, ამიტომ მონაცემებს ორჯერ არ ტვირთავს.

ჯერ dump ლოკალურ დისკზე აიღე. ჩაწერე ფაილში, შეამოწმე გასვლის კოდი, გადაამოწმე ფაილი (pg_restore --list dump.file > /dev/null სრულ სარჩევს კითხულობს და მოჭრილ custom ფორმატის ფაილზე მარცხდება), შემდეგ ატვირთე. ამას სჭირდება თავისუფალი ლოკალური დისკი შეკუმშული dump-ის ზომით, და სანაცვლოდ ყველაზე ძლიერ შემოწმებას გაძლევს.

დაახლოებით 50 GB-ზე დიდი სტრიმებისთვის AWS CLI-ს ასევე სჭირდება --expected-size ზომის შეფასებით ბაიტებში, რომ საკმარისად დიდი ნაწილების ზომა აირჩიოს და multipart-ის 10,000 ნაწილის ლიმიტს ქვემოთ დარჩეს. ამაზე ნაკლებისთვის ნაგულისხმევი მნიშვნელობები კარგია.

დაშიფვრა#

მონაცემთა ბაზის dump ყველაზე მგრძნობიარე ფაილია, რაც გაქვს: ყველა მომხმარებელი, ყველა hash, ყველა მისამართი. თუ bucket-ის გასაღებები ოდესმე გაჟონავს, dump-ებიც მათთან ერთად გაჟონავს. დაშიფრე ატვირთვამდე, რომ საცავში მხოლოდ დაშიფრული ტექსტი ინახებოდეს.

age ამისთვის ყველაზე მარტივი ხელსაწყოა. გასაღებების წყვილი ერთხელ შექმენი მანქანაზე, რომელიც backup-ის მანქანა არ არის, პირადი გასაღები offline შეინახე და დავალებაში მხოლოდ საჯარო გასაღები ჩადე:

$ age-keygen -o backup-key.txt          # on your own machine; keep this file safe$ pg_dump ... -Fc | age -r age1qz...publickey... \    | aws s3 cp - "s3://db-dumps/pg/app/$(date -u +%F).dump.age" --profile store

backup-ის მანქანას შეუძლია დაშიფვრა, მაგრამ არა გაშიფვრა, ამიტომ თავდამსხმელი, რომელიც backup-ის მანქანას ხელში ჩაიგდებს, bucket-იდან ძველ dump-ებს ვერ წაიკითხავს. აღსადგენად: aws s3 cp s3://.../file.dump.age - | age -d -i backup-key.txt | pg_restore .... gpg --symmetric-იც მუშაობს, მაგრამ backup-ის მანქანაზე passphrase სჭირდება, რაც ამ თვისებას კარგავს. რაც არ უნდა აირჩიო, გაშიფვრის გასაღები შეინახე იქ, სადაც ის სერვერის გაქრობის შემდეგაც გექნება - პაროლების მენეჯერში, დაბეჭდილი უჯრაში - თორემ დაშიფრული dump-ები უბრალოდ ხმაურია.

შენახვის ვადა lifecycle-ის წესების გარეშე#

გასაღებები ისე დაასახელე, რომ თარიღით დალაგდეს - pg/app/2026-10-08_0400.dump - და სახელით წაშალე. sync ხელსაწყოებში --min-age-ის ტიპის ფილტრებს ნუ დაეყრდნობი; ისინი ცვლილების დროს იყენებს, რაც ყოველთვის არ ნიშნავს "როდის აიღეს ეს backup".

ბაბუა-მამა-შვილის სქემა სამი prefix-ით ინახავს ერთი კვირის ყოველდღიურებს, ერთი თვის ყოველკვირეულებს და ერთი წლის ყოველთვიურებს. კვირაობით იმ ღამის dump weekly/-ში დააკოპირე; თვის 1-ში - monthly/-ში. სერვერის მხარეს კოპირება ატვირთვას არ საჭიროებს:

#!/usr/bin/env bashset -euo pipefailP="--profile store"B="s3://db-dumps/pg/app"TODAY=$(date -u +%F)LATEST=$(aws s3 ls "$B/" $P | awk '{print $4}' | grep "^$TODAY" | sort | tail -n1)[ -n "$LATEST" ] || exit 1if [ "$(date -u +%u)" = 7 ]; then aws s3 cp "$B/$LATEST" "$B/weekly/$LATEST" $P; fiif [ "$(date -u +%d)" = 01 ]; then aws s3 cp "$B/$LATEST" "$B/monthly/$LATEST" $P; fiprune() {  # prune <prefix> <days>  local cutoff; cutoff=$(date -u -d "$2 days ago" +%F)  { aws s3 ls "$1/" $P || true; } | awk '{print $4}' | while read -r k; do    if [ -n "$k" ] && [[ "${k:0:10}" < "$cutoff" ]]; then aws s3 rm "$1/$k" $P; fi  done}prune "$B" 7prune "$B/weekly" 35prune "$B/monthly" 366

aws s3 ls prefix-ზე ობიექტებს მეოთხე სვეტში აჩვენებს, საქაღალდეებს კი PRE ხაზებად, რომლებსაც ცარიელობის შემოწმება გამოტოვებს. ის ასევე შეცდომით გადის, როცა prefix-ში ჯერ არაფერია - პირველ კვირას, სანამ რომელიმე ყოველკვირეული ასლი გაჩნდება - და სწორედ ამიტომ არის ეს გამოძახება || true-ში შეფუთული; მის გარეშე pipefail სკრიპტს პირველივე გაშვებაზე გააჩერებდა. cron-იდან dump 04:00-ზე გაუშვი, ეს კი 04:30-ზე, და თითოეულის ბოლოს dead-man's-switch ping დაამატე, რომ გაიგო იმ ღამის შესახებ, როცა ის არ გაეშვება. cron-ის გამოსახულებების ახსნა განრიგის სინტაქსს განიხილავს.

bucket-ის ზომა პოლიტიკიდან გამოთვალე. შვიდი ყოველდღიური, ხუთი ყოველკვირეული და თორმეტი ყოველთვიური 24 dump-ია; 400 MB-იანი შეკუმშული dump-ით ეს დაახლოებით 10 GB გამოდის, და ბაზის ზრდა მას პროპორციულად ზრდის.

აღდგენის ტესტირება#

backup, რომელიც არავის აღუდგენია, ჰიპოთეზაა. თვეში ერთხელ, ან დავალების ნებისმიერი ცვლილების შემდეგ:

1. ჩამოტვირთე ბოლო dump და გაშიფრე.
2. აღადგინე სატესტო ბაზაში - ლოკალური Docker კონტეინერი იდეალურია: docker run --rm -e POSTGRES_PASSWORD=x -p 5433:5432 postgres:17.
3. გაუშვი query, რომელიც მხოლოდ რეალურ მონაცემებზე მუშაობს: მთავარ ცხრილებში ხაზების რაოდენობა, უახლესი შეკვეთის დრო.
4. ჩაინიშნე, რამდენი ხანი დასჭირდა. ეს არის შენი რეალური აღდგენის დრო, და ის ჩვეულებრივ იმაზე მეტია, ვიდრე ხალხი ვარაუდობს.

მონაცემთა ბაზის backup-ები და აღდგენა და აღდგენის ტესტირება მანამ, სანამ დაგჭირდება ამას რუტინად აქცევს.

FAQ#

რამდენად ხშირად უნდა ავიღო მონაცემთა ბაზის dump?

ყოველდღიური dump პატარა აპლიკაციების უმეტესობას ფარავს. ინტერვალი არის მონაცემების მაქსიმუმი, რისი დაკარგვაც შეგიძლია, ამიტომ მაღაზიას, რომელიც მთელი დღე იღებს შეკვეთებს, შეიძლება dump-ები ყოველ რამდენიმე საათში დასჭირდეს, მათ შორის კი პანელის backup-ები. ამის მიღმა შემდეგი ნაბიჯი უწყვეტი არქივირებაა (WAL Postgres-ისთვის, binlog-ები MySQL-ისთვის), და ეს სხვა დავალებაა.

უნდა შევკუმშო dump-ები ატვირთვამდე?

კი, თუ ფორმატი უკვე შეკუმშული არ არის. PostgreSQL-ის custom ფორმატი შეკუმშულია; mongodump --gzip-იც. ჩვეულებრივი mysqldump ტექსტია და zstd-ით ან gzip-ით ხუთიდან ათჯერ მცირდება.

შეიძლება dump-ის აღება, სანამ აპლიკაცია მუშაობს?

კი. pg_dump და mysqldump --single-transaction თანმიმდევრულ snapshot-ს ჩაწერის დაბლოკვის გარეშე კითხულობს. მაინც მშვიდ საათში გაუშვი; dump ყველა ხაზს კითხულობს და რეალურ query-ებს დისკისა და CPU-სთვის ეჯიბრება.

საკმარისია ერთი ასლი S3-ში?

ეს კარგი მეორე ასლია და არა ერთადერთი. მაგალითად, RE:NODE-ის საცავი ერთ ასლს NVMe-ზე ერთ ლოკაციაში ინახავს, რეპლიკაციის გარეშე. პანელის backup-ებიც შეინახე და თვეში ერთი dump სულ სხვა ადგილას ჩამოტვირთე.

როგორ გავიგო, რომ დავალება ისევ ეშვება?

ყოველი წარმატებული გაშვების ბოლოს მონიტორინგის სერვისს ping გაუგზავნოს, და გაფრთხილება დააყენე, როცა ping არ მოდის. დროდადრო უახლესი dump-ის ზომაც შეამოწმე: მკვეთრი ვარდნა რამდენიმე კილობაიტამდე ნიშნავს, რომ რაღაც არასწორადაა, მაშინაც კი, თუ ყველა ნაბიჯი "წარმატებით შესრულდა".