Categories
Database Backup

** Discover the hidden dangers of DIY database backup scripts. Learn why custom Bash scripts fail in production, the risks of logical dumps, and how to secure your data with enterprise solutions.

Ikvienam datubāzu administratoram (DBA) un sistēmu inženierim savas karjeras laikā ir nācies uzrakstīt pielāgotu čaulas (shell) skriptu datubāzes dublēšanai. Tas praktiski ir kā iniciācijas rituāls. Projekta sākumposmā vienkāršs cron uzdevums, kas izpilda mysqldump vai pg_dump un novirza rezultātu uz gzip, šķiet kā elegants, viegls un izmaksu ziņā efektīvs risinājums.

Tomēr, infrastruktūrai paplašinoties, datu apjomiem augot un darbības nepārtrauktības (uptime) SLA kļūstot stingrākiem, šis 10 rindiņu Bash skripts klusi pārvēršas par laika bumbu. Ražošanas vide pieprasa augstu pieejamību, stingrus atkopšanas punkta mērķus (RPO) un ātrus atkopšanas laika mērķus (RTO). Pašrocīgi veidotu dublēšanas skriptu izmantošana šādās vidēs rada nopietnus riskus, kas saistīti ar datu konsekvenci, klūmēm, kuras netiek pamanītas, drošības ievainojamībām un nevadāmiem atkopšanas procesiem.

Šajā rakstā mēs analizēsim pašrocīgo datubāzu dublēšanas skriptu arhitektūras nepilnības un slēptās briesmas, izpētīsim loģisko un fizisko dublējumu tehniskos trūkumus un apspriedīsim, kā pāriet uz uzņēmuma līmeņa risinājumiem, piemēram, CloudSave, lai aizsargātu jūsu kritiski svarīgos datus.

Vienkāršības ilūzija: Klasiskā pašrocīgā skripta analīze

Lai saprastu briesmas, vispirms ir jāaplūko tipiska pašrocīga dublēšanas skripta uzbūve. Standarta pieeja MySQL datubāzei bieži izskatās šādi:

#!/bin/bash
# Vienkāršs pašrocīgs MySQL dublēšanas skripts
BACKUP_DIR="/mnt/backups"
DATE=$(date +%F)
DB_USER="admin"
DB_PASS="SuperSecret123!"

mysqldump -u $DB_USER -p$DB_PASS my_database | gzip > $BACKUP_DIR/mydb_$DATE.sql.gz

# Dzēst dublējumus, kas vecāki par 30 dienām
find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +30 -exec rm {} ;

No pirmā acu uzmetiena šis skripts sasniedz mērķi: tas izgūst datus, saspiež tos un pārvalda to glabāšanas ilgumu. Taču zem virsmas tas ir pilns ar kritiskiem trūkumiem, kas ražošanas vidē galu galā novedīs pie datu zuduma.

1. briesmas: Klūmes, kuras netiek pamanītas, un “cauruļvada” slazds

Viena no mānīgākajām pašrocīgo skriptu briesmām ir klūmes, kas netiek pamanītas. Iepriekš minētajā skriptā mysqldump komanda tiek novirzīta (|) tieši uz gzip.

Bash vidē cauruļvada (pipeline) izejas statuss ir pēdējās komandas izejas statuss. Ja datubāzes serverim beidzas atmiņa, tiek pārtraukts savienojums vai dublēšanas laikā rodas bloķēta tabula, mysqldump neizdosies un izmetīs kļūdu. Tomēr gzip veiksmīgi saspiež saņemto daļējo izvadi un izies ar statusa kodu 0 (veiksme).

Jūsu uzraudzības sistēma, pārbaudot cron uzdevuma izejas kodu, ziņos par veiksmīgu dublējumu. Diskā jums būs derīgs .gz fails, bet iekšpusē būs apgriezts, nelietojams SQL fails. Jūs to neatklāsiet, līdz nemēģināsiet veikt kritisku atkopšanu.

Mazināšana (un tās ierobežojumi)

Inženieri bieži mēģina to labot, iespējojot stingru kļūdu apstrādi Bash vidē:

set -e
set -o pipefail

Lai gan set -o pipefail nodrošina, ka skripts neizdodas, ja jebkura komanda cauruļvadā neizdodas, tas joprojām prasa izveidot stabilus brīdināšanas, reģistrēšanas un atkārtotas mēģināšanas mehānismus ap skriptu. Kad īslaicīga tīkla kļūda izraisa neveiksmi plkst. 2:00 naktī, pašrocīgs skripts vienkārši apstājas. Uzņēmuma līmeņa platformas apstrādā šīs īslaicīgās kļūdas ar inteliģentiem, eksponenciāliem atkārtotiem mēģinājumiem.

2. briesmas: Datu konsekvence un bloķēšanas murgi

Pašrocīgie skripti lielā mērā paļaujas uz loģiskajiem dublējumiem (mysqldump, pg_dump). Loģiskie dublējumi izgūst datus, izpildot SELECT vaicājumus visās tabulās. Augsti transakcionālā ražošanas datubāzē dati pastāvīgi mainās. Ja skriptam ir nepieciešamas 45 minūtes, lai izgāztu 100 GB datubāzi, dati dublējuma sākumā būs par 45 minūtēm vecāki nekā dati beigās, pārkāpjot ACID atbilstību.

MySQL transakciju konsekvence

Lai panāktu konsekventu momentuzņēmumu MySQL, izmantojot InnoDB, jums ir jāizmanto īpaši karogi:

mysqldump --single-transaction --quick --routines --events -u user -p db > dump.sql

Karogs --single-transaction iestata izolācijas līmeni uz REPEATABLE READ un sāk transakciju pirms izgāšanas. Tomēr, ja jūsu datubāzē joprojām ir mantotās MyISAM tabulas, šis karogs nepasargās tās no bloķēšanas, potenciāli apturot ražošanas lasīšanas/rakstīšanas trafiku dublēšanas laikā. Turklāt jebkuri ALTER TABLE, DROP TABLE vai RENAME TABLE paziņojumi, ko izstrādātāji izpilda dublēšanas laikā, pārtrauks REPEATABLE READ momentuzņēmumu, izraisot dublējuma neveiksmi.

PostgreSQL un WAL arhivēšana

PostgreSQL gadījumā pg_dump nodrošina konsekventus loģiskos dublējumus, taču tikai ar loģiskajiem dublējumiem nevar nodrošināt atkopšanu līdz noteiktam laika punktam (PITR). Ja jūsu datubāze avarē plkst. 16:00 un pēdējais cron skripts darbojās pusnaktī, jūs zaudējat 16 stundu datus.

PITR sasniegšanai ir nepieciešama nepārtraukta Write-Ahead Logs (WAL) arhivēšana. Uzrakstīt pašrocīgu skriptu, lai droši apstrādātu archive_command, ir ārkārtīgi grūti.

# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /mnt/wal_archive/%f && cp %p /mnt/wal_archive/%f'

Ja mērķa krātuve (/mnt/wal_archive/) aizpildās vai kļūst nepieejama, archive_command neizdosies. PostgreSQL pēc tam uzkrās WAL failus lokāli, līdz primārais disks būs pilns, izraisot pilnīgu datubāzes darbības pārtraukumu. Pašrocīgajiem skriptiem reti ir telemetrija, kas nepieciešama, lai uzraudzītu WAL uzkrāšanos un brīdinātu administratorus pirms darbības pārtraukuma rašanās.

3. briesmas: Glabāšanas ilguma rulete

Paskatieties atpakaļ uz glabāšanas ilguma komandu mūsu sākotnējā skriptā:

find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +30 -exec rm {} ;

Šis ir katastrofāls datu zuduma notikums, kas tikai gaida savu kārtu. Iedomājieties scenāriju, kurā konfigurācijas izmaiņas pārtrauc mysqldump autentifikāciju. Skriptam neizdodas izveidot jaunus dublējumus, bet find komanda turpina darboties katru nakti, pienācīgi dzēšot failus, kas vecāki par 30 dienām.

Pēc 30 dienām, kad dublēšana klusi nav izdevusies, find komanda izdzēsīs jūsu pēdējo atlikušo labo dublējumu. Jums vairs nav neviena dublējuma.

Uzņēmuma līmeņa dublēšanas programmatūra, piemēram, CloudSave, izmanto stāvokļa glabāšanas politikas. Tā saprot atšķirību starp “dzēst dublējumus, kas vecāki par 30 dienām” un “nodrošināt, ka pirms veco datu dzēšanas pastāv vismaz 30 veiksmīgi atkopšanas punkti”.

4. briesmas: Drošība, šifrēšana un atbilstības “aklās zonas”

Izspiedējvīrusu un stingru atbilstības sistēmu (GDPR, HIPAA, SOC 2) laikmetā dublējumi ir galvenais mērķis. Pašrocīgie skripti bieži pārkāpj drošības labāko praksi:

  1. Iekodēti akreditācijas dati: Datubāzes paroļu glabāšana vienkāršā tekstā skriptos vai cron definīcijās ir milzīgs drošības risks. Lai gan tādi rīki kā MySQL mysql_config_editor vai PostgreSQL .pgpass fails to mazina, tie joprojām prasa pārvaldīt lokālos atslēgu failus serverī.
  2. Šifrēšanas trūkums glabāšanas laikā: Neapstrādāta SQL izgāšana diskā atstāj sensitīvus PII/PHI datus neaizsargātus.
  3. Sarežģīti šifrēšanas cauruļvadi: Mēģinājumi šifrēt dublējumus “lidojumā”, izmantojot GPG, rada nopietnu CPU slodzi un atslēgu pārvaldības sarežģījumus.
# Pašrocīgs šifrēts dublēšanas cauruļvads
pg_dump mydb | gzip | gpg --symmetric --cipher-algo AES256 --passphrase-file /etc/keys/backup.key > backup.sql.gz.gpg

Ja serveris tiek kompromitēts, uzbrucējam ir piekļuve gan šifrētajam dublējumam, gan /etc/keys/backup.key failam, padarot šifrēšanu bezjēdzīgu. Turklāt, ja DBA, kurš ģenerēja GPG atslēgu, pamet uzņēmumu un atslēga tiek pazaudēta, dublējumi nav atkopjami.

5. briesmas: RTO realitātes pārbaude (Atkopšana ir grūtāka nekā dublēšana)

Dublējuma galīgais pārbaudījums ir atkopšana. Pašrocīgo skriptu ģenerētos loģiskos dublējumus ir bēdīgi grūti atjaunot. 500 GB SQL izgāzuma izveide var aizņemt 15 minūtes, taču tā atjaunošana prasa, lai datubāzes dzinējs parsētu SQL, pārbūvētu indeksus un pārrēķinātu ierobežojumus. Tas var aizņemt stundas vai pat dienas, iznīcinot jūsu RTO.

Lielām ražošanas datubāzēm fiziskie dublējumi (faktisko datu failu kopēšana) ir obligāti. Lai gan pastāv tādi rīki kā Percona XtraBackup vai pg_basebackup, to ietīšana pašrocīgos Bash skriptos ir ārkārtīgi sarežģīta. Jums ir jāpārvalda LVM momentuzņēmumi, jāapstrādā failu sistēmas klusināšana un jānodrošina, ka dublējums tiek pārsūtīts ārpus vietnes, nepārslogojot tīkla saskarni.

LVM momentuzņēmuma slazds

Daudzi inženieri mēģina veikt “nulles dīkstāves” fiziskos dublējumus, izmantojot LVM momentuzņēmumus:

# Izveidot momentuzņēmumu
lvcreate --size 20G --snapshot --name db_snap /dev/vg0/db_vol

# Piestiprināt un kopēt
mount /dev/vg0/db_snap /mnt/snap
tar -czf /backups/db_physical.tar.gz /mnt/snap/mysql

Ja datubāzē rodas pēkšņs rakstīšanas I/O pieaugums, 20G LVM momentuzņēmums var acumirklī aizpildīties. Kad LVM momentuzņēmums aizpildās, tas kļūst nederīgs un dublēšana neizdodas. Vēl sliktāk, intensīvi izmantoti LVM momentuzņēmumi var nopietni pasliktināt primārā datubāzes sējuma I/O veiktspēju, izraisot lietojumprogrammas latentuma lēcienus.

Pāreja uz uzņēmuma līmeņa aizsardzību

Pāreja no pašrocīgiem skriptiem uz uzņēmuma līmeņa platformu ir kritisks brieduma posms jebkurai infrastruktūras komandai. Mērķis ir pāriet no “cerības, ka skripts darbojās” uz kriptogrāfisku pierādījumu par atkopjamību.

Tādas platformas kā CloudSave ir īpaši izstrādātas, lai novērstu pašrocīgo skriptu aklās zonas. Izvietojot lietojumprogrammu apzinošus aģentus, CloudSave tieši mijiedarbojas ar datubāzu API (MySQL, PostgreSQL, MS SQL, Oracle), lai organizētu konsekventus fiziskos un loģiskos dublējumus, nebloķējot tabulas un nesamazinot veiktspēju.

Galvenās priekšrocības, atsakoties no skriptiem:

  1. Automatizēta pārbaude: Mūsdienu platformas ne tikai veic dublējumus; tās tos pārbauda. CloudSave var automātiski iedarbināt pagaidu datubāzes instanci, atjaunot dublējumu, veikt konsekvences pārbaudes (piemēram, DBCC CHECKDB) un to izslēgt, sniedzot verificētu ziņojumu, ka dublējums patiešām ir izmantojams.
  2. Nemainīga krātuve: Lai cīnītos ar izspiedējvīrusiem, dublējumiem jābūt nemainīgiem. Pašrocīgie skripti nevar viegli rakstīt WORM (Write Once, Read Many) krātuvē. Uzņēmuma līmeņa risinājumi dabiski integrējas ar S3 Object Lock un nemainīgu mākoņkrātuvi, nodrošinot, ka pat tad, ja serveris ir pilnībā kompromitēts, uzbrucējs nevar izdzēst vai šifrēt dublējumus.
  3. Vienkāršota PITR: Tā vietā, lai manuāli sastiķētu kopā bāzes dublējumu un simtiem WAL failu, izmantojot sarežģītus recovery.conf vai postgresql.auto.conf parametrus, platformas nodrošina vizuālu laika skalu. Jūs vienkārši atlasāt precīzu minūti, uz kuru vēlaties atjaunot, un programmatūra automātiski apstrādā žurnāla atskaņošanu.
  4. Deduplikācija un saspiešana: Pašrocīgie skripti paļaujas uz gzip, kas saspiež katru failu atsevišķi. Uzņēmuma līmeņa dublēšanas programmatūra izmanto globālu bloku līmeņa deduplikāciju, krasi samazinot uzglabāšanas izmaksas un tīkla joslas platumu, pārsūtot dublējumus ārpus vietnes.

Secinājums

Uzrakstīt pielāgotu Bash skriptu datubāzes dublēšanai ir viegli. Uzrakstīt skriptu, kas apstrādā klusas cauruļvada kļūmes, garantē ACID konsekvenci, droši pārvalda kriptogrāfiskās atslēgas, novērš datu zudumu glabāšanas ilguma dēļ un garantē stingrus RTO/RPO SLA, ir gandrīz neiespējami.

Ražošanas vidēs datubāze ir uzņēmuma vissvarīgākais aktīvs. Tās aizsardzības uztveršana kā blakusprojekts, ko uztur daži simti čaulas skripta rindiņu, ir risks, ko neviens uzņēmums nevar atļauties. Auditējot savas pašreizējās dublēšanas stratēģijas, izprotot loģisko izgāzumu ierobežojumus un migrējot uz stabilām, automatizētām platformām, piemēram, CloudSave, DevOps un DBA komandas var novērst pielāgoto skriptu “autobusa faktoru” un nodrošināt, ka to dati ir patiesi noturīgi.

Kategorijas