Categories
Database Backup

** Discover how DevOps engineers and DBAs can detect corrupted database backups before disaster strikes. Learn advanced techniques for PostgreSQL, SQL Server, and MySQL, including automated restore testing and checksum validation.

אין דער וועלט פון דאַטאַבייס אַדמיניסטראַציע און זייטל-פאַרלאָזלעכקייט אינזשעניריע (SRE), איז דאָ אַ באַקאַנטער אַקסיאָם: שראָדדינגערס באַקאַפּ. דער צושטאַנד פון קיין באַקאַפּ איז אומבאַקאַנט ביז איר פּרוּווט עס צו רעסטאָרן. ביז דעם מאָמענט, עקזיסטירט עס אין אַ קוואַנטום-צושטאַנד פון זיין סיי פּערפעקטלי גילטיק און סיי גאָר פאַרדאָרבן.

פֿאַר DevOps אינזשענירן און דאַטאַבייס אַדמיניסטראַטאָרן (DBAs), צו אַנטדעקן אַז אַ קריטישער דאַטאַבייס-באַקאַפּ איז פאַרדאָרבן בעשאַס אַן אַקטיוון אינצידענט איז דער ערגסטער נייטמער. עס פאַרוואַנדלט אַ רוטין רעסטאָר-אָפּעראַציע אין אַ קאַטאַסטראָפאַלע דאַטן-פאַרלוסט. דער “שטילער מערדער” פון דאַטן-אינטעגריטעט בלייבט אָפט אומבאַמערקט, ווייל באַקאַפּ-אַרבעט באַריכטעט אָפט אַ מצליחדיקן Exit Code 0, אפילו ווען די דאַטן זענען פאַרדאָרבן.

אין דעם פולשטענדיקן וועגווייַזער, וועלן מיר אַנאַליזירן די אַנאַטאָמיע פון באַקאַפּ-קאָרופּציע, ויספאָרשן דאַטאַבייס-ספּעציפישע וואַלידאַציע-טעכניקן, און ווייַזן ווי אַזוי צו בויען אָטאַמאַטיזירטע, פאַרלאָזלעכע רעסטאָר-פּייפּליינז פֿאַר פּראָדוקציע-סביבות.

די אַנאַטאָמיע פון באַקאַפּ-קאָרופּציע

כדי צו דעטעקטירן קאָרופּציע, מוזט איר ערשט פאַרשטיין ווי אַזוי עס פּאַסירט. באַקאַפּ-קאָרופּציע פאַלט אַלגעמיין אין צוויי קאַטעגאָריעס: פיזישע (אינפראַסטרוקטור-מדרגה) און לאָגישע (אַפּליקאַציע-מדרגה).

פיזישע קאָרופּציע

פיזישע קאָרופּציע פּאַסירט ווען די פאַקטישע ביטן אויף דעם סטאָרידזש-מיטל ווערן געביטן. דאָס קען פּאַסירן בעשאַס דעם לייענען-פּראָצעס פון דעם מקור-דיסק, בעשאַס נעטוואָרק-טראַנספּאָרט, אָדער ווען עס ליגט אויף דעם ציל-סטאָרידזש.
* ביט ראָט (Bit Rot): גראַדועלע דעגראַדאַציע פון סטאָרידזש-מיטלען קען שטילערהייט טוישן ביטן.
* טראַנספּאָרט-טעותים: כאָטש TCP האָט טשעקסומס, זענען זיי באַקאַנט ווי שוואַך (16-ביט). סביבות מיט הויכע דורכפאָר-קאַפּאַציטעט קענען דערפֿאָרן שטילע דאַטן-קאָרופּציע איבער די קאַבלען וואָס TCP באַמערקט נישט.
* סטאָרידזש קאָנטראָלער-פעלערן: האַרדווער-באָגס אין RAID קאָנטראָלערס אָדער SAN פאַבריקס קענען שרייבן אומנוצליכע דאַטן בשעת זיי באַריכטן הצלחה צו דעם OS.

לאָגישע קאָרופּציע

לאָגישע קאָרופּציע איז מסתּמא געפערלעכער, ווייל דער באַקאַפּ-טעקע אַליין איז פּערפעקטלי גאַנץ, אָבער די דאַטן אינעווייניק זענען צעשטערט.
* Garbage In, Garbage Out (GIGO): אויב אייער לעבעדיקער דאַטאַבייס האָט אַ פאַרדאָרבענע אינדעקס אָדער אַ צעריסענע בלאַט, קען אייער באַקאַפּ-געצייג געטריי קאָפּירן יענע פאַרדאָרבענע בלאַט. די באַקאַפּ-אַרבעט איז מצליח, אָבער דער רעסטאָר וועט דורכפאַלן אָדער פּראָדוצירן אַ צעשטערטן דאַטאַבייס.
* אומקאָמפּלעטע טראַנזאַקציעס: פייל-סיסטעם מדרגה סנאַפּשאָץ וואָס ווערן גענומען אָן ריכטיק פריזינג פון דאַטאַבייס I/O (למשל, נישט ניצן FLUSH TABLES WITH READ LOCK אין MySQL) רעזולטירן אין צעריסענע בלעטער און אומרעסטאָרירבאַרע צושטאַנדן.

פּראָאַקטיווע דעטעקשאַן: טשעקסומס און קריפּטאָגראַפישע האַשינג

די ערשטע ליניע פון פאַרטיידיקונג קעגן פיזישע קאָרופּציע איז קריפּטאָגראַפישע וואַלידאַציע. זיך פאַרלאָזן אויף טעקע-גרייס אָדער מאָדיפיקאַציע-דאַטעס איז ניט גענוג.

ענייבלינג דאַטאַבייס-מדרגה טשעקסומס

מאָדערנע רעליישאַנאַל דאַטאַבייס-מאַנאַגעמענט סיסטעמען (RDBMS) שטיצן בלאַט-מדרגה טשעקסומס. ווען ענייבלד, רעכנט דער דאַטאַבייס אויס אַ טשעקסום פֿאַר יעדער בלאַט איידער עס ווערט געשריבן אויף דיסק. ווען די בלאַט ווערט געלייענט (צי דורך אַ קווערי אָדער אַ באַקאַפּ-פּראָצעס), ווערט דער טשעקסום וועריפיצירט.

פֿאַר PostgreSQL, קענט איר ענייבלן דאַטן-טשעקסומס בעשאַס קלאַסטער-איניציאַליזירונג:

# Initialize a new PostgreSQL cluster with checksums enabled
initdb --data-checksums -D /var/lib/postgresql/data

באַמערקונג: אויב איר האָט אַן עקזיסטירנדן PostgreSQL קלאַסטער, קענט איר נוצן די pg_checksums נוצן צו ענייבלן זיי אָפפלינע.

פֿאַר Microsoft SQL Server, פאַרזיכערט זיך אַז PAGE_VERIFY איז געשטעלט אויף CHECKSUM (דאָס איז די דעפאָלט אין מאָדערנע ווערסיעס, אָבער עס איז כדאי צו וועריפיצירן אויף עלטערע סיסטעמען):

ALTER DATABASE [ProductionDB] SET PAGE_VERIFY CHECKSUM;
GO

וועריפיצירן באַקאַפּס אין רו (At Rest)

אַמאָל דער באַקאַפּ לאַנדט אויף אייער סטאָרידזש-ציל, מוז זיין אינטעגריטעט קריפּטאָגראַפיש וועריפיצירט ווערן. ענטערפּרייז באַקאַפּ-פּלאַטפאָרמס ווי CloudSave רעכענען אויטאָמאַטיש אויס און וועריפיצירן SHA-256 האַשעס פון באַקאַפּ-בלאַקס בעשאַס טראַנספּאָרט און אין רו. אויב איר פירט אייגענע סקריפּטן, מוזט איר דאָס אימפּלעמענטירן מאַנועל:

# Generate SHA-256 hash after backup creation
sha256sum prod_db_backup.tar.gz > prod_db_backup.tar.gz.sha256

# Verify the hash on the storage server
sha256sum -c prod_db_backup.tar.gz.sha256

דאַטאַבייס-ספּעציפישע וואַלידאַציע-טעכניקן

פאַרשידענע דאַטאַבייס-ענדזשינז פאָרשלאָגן געבוירענע געצייג צו וועריפיצירן די אינטעגריטעט פון זייערע באַקאַפּ-אַרטיפאַקטן.

PostgreSQL: pg_verifybackup

איינגעפירט אין PostgreSQL 13, איז pg_verifybackup אַ גרויסע הילף פֿאַר פיזישע באַקאַפּס גענומען מיט pg_basebackup. עס לייענט דעם backup_manifest טעקע וואָס ווערט געשאפן בעשאַס דעם באַקאַפּ און וועריפיצירט אַז אַלע טעקעס זענען דאָ און זייערע טשעקסומס שטימען.

# Run verification against a physical base backup directory
pg_verifybackup /mnt/backups/postgres/base_backup_20231025/

אויב אַ איין ביט האָט זיך געביטן אין קיין איינע פון די דאַטן-טעקעס, וועט pg_verifybackup וואַרפן אַ פאַטאַלן טעות, וואָס לאָזט אייערע מאָניטאָרינג-סיסטעמען גלייך אַלאַרמירן די DBA מאַנשאַפט.

Microsoft SQL Server: RESTORE VERIFYONLY

SQL Server גיט אַ געבוירענע באַפעל צו וועריפיצירן די פיזישע אינטעגריטעט פון אַ באַקאַפּ-טעקע אָן טאַקע רעסטאָרן עס. עס טשעקט די באַקאַפּ-העדערס און וועריפיצירט די בלאַט-טשעקסומס (אויב זיי זענען געווען ענייבלד בעשאַס דעם באַקאַפּ).

RESTORE VERIFYONLY 
FROM DISK = 'Z:BackupsProdDB_Full.bak' 
WITH CHECKSUM;

וואָרענונג: RESTORE VERIFYONLY באַשטעטיקט בלויז אַז די באַקאַפּ-טעקע איז לייענבאַר און פיזישע טשעקסומס שטימען. עס גאַראַנטירט נישט לאָגישע אינטעגריטעט. צו פאַרזיכערן לאָגישע אינטעגריטעט, מוזט איר דורכפירן אַ פולן רעסטאָר און לויפן DBCC CHECKDB.

MySQL / InnoDB: Percona XtraBackup

פֿאַר MySQL סביבות, ווערן פיזישע באַקאַפּס אָפט באַהאַנדלט דורך Percona XtraBackup. דער באַקאַפּ-פּראָצעס באַשטייט פון קאָפּירן טעקעס, אָבער דער באַקאַפּ איז נישט קאָנסיסטענט ביז די טראַנזאַקציע-לאָגס (redo logs) ווערן אַפּלייד. די --prepare פאַזע דינט ווי אַ געבויטע אינטעגריטעט-טשעק.

# Preparing the backup applies the redo logs. 
# If the backup is corrupted, this step will fail.
xtrabackup --prepare --target-dir=/data/backups/mysql/

דער גאָלדענער סטאַנדאַרט: אָטאַמאַטיזירטע רעסטאָר-טעסטינג

טשעקסומס און וועריפיקאַציע-באפעלן זענען נויטיק, אָבער זיי זענען נישט גענוג. דער איינציקער וועג צו דעפיניטיוו באַווייַזן אַז אַ באַקאַפּ איז גילטיק איז צו רעסטאָרן עס. אין מאָדערנע DevOps סביבות, מוז דער פּראָצעס זיין גאָר אָטאַמאַטיזירט.

דורך באַהאַנדלען באַקאַפּס ווי קאָד, קענט איר בויען אַ CI/CD פּייפּליין פֿאַר אייערע דאַטאַבייס-רעסטאָרס. דער פּייפּליין זאָל פּראָוויזשאַנירן עפעמערע אינפראַסטרוקטור, דורכפירן דעם רעסטאָר, לויפן וואַלידאַציע-קוועריס, און אויסמעקן די סביבה.

בויען אַן אָטאַמאַטיזירטן רעסטאָר-פּייפּליין

ונטן איז אַ ביישפּיל פון אַ Bash סקריפּט וואָס קען ווערן טריגערד טעגלעך דורך אַ cron job אָדער אַ CI runner (ווי GitLab CI אָדער GitHub Actions) צו וואַלידירן אַ PostgreSQL לאָגישן דאַמפּ.

#!/bin/bash
set -e

BACKUP_FILE="/mnt/storage/prod_db_latest.dump"
DB_NAME="prod_db"
CONTAINER_NAME="pg_restore_test"

echo "[INFO] Starting Automated Restore Test..."

# 1. Spin up an ephemeral PostgreSQL container
docker run --name $CONTAINER_NAME 
  -e POSTGRES_PASSWORD=testpass 
  -d postgres:15

# Wait for PostgreSQL to be ready
echo "[INFO] Waiting for database to initialize..."
until docker exec $CONTAINER_NAME pg_isready -U postgres; do
  sleep 2
done

# 2. Create the target database
docker exec $CONTAINER_NAME psql -U postgres -c "CREATE DATABASE $DB_NAME;"

# 3. Execute the restore
echo "[INFO] Restoring backup..."
docker cp $BACKUP_FILE $CONTAINER_NAME:/tmp/backup.dump
docker exec $CONTAINER_NAME pg_restore -U postgres -d $DB_NAME -1 /tmp/backup.dump

# 4. Run Logical Validation Queries
echo "[INFO] Running validation queries..."
# Check if the users table has more than 10,000 records
USER_COUNT=$(docker exec $CONTAINER_NAME psql -U postgres -d $DB_NAME -t -c "SELECT COUNT(*) FROM users;")

if [ "$USER_COUNT" -lt 10000 ]; then
    echo "[ERROR] Logical validation failed. Expected >10000 users, found $USER_COUNT"
    # Trigger PagerDuty / Slack alert here
    exit 1
else
    echo "[SUCCESS] Logical validation passed. User count: $USER_COUNT"
fi

# 5. Tear down ephemeral environment
echo "[INFO] Cleaning up..."
docker rm -f $CONTAINER_NAME

echo "[INFO] Automated Restore Test Completed Successfully."

וואָס זאָלט איר וואַלידירן?

ווען איר פירט דורכ אָטאַמאַטיזירטע רעסטאָר-טעסטינג, טשעקט נישט בלויז אויב דער דאַטאַבייס הייבט זיך אָן. לויפט אַפּליקאַציע-ספּעציפישע וואַלידאַציע-קוועריס:
1. ריי-ציילונגען (Row Counts): פאַרזיכערט זיך אַז קאָר-טעבלעס האָבן די ערוואַרטע ריי-ציילונגען (למשל, users טעבל זאָל נישט זיין ליידיק).
2. לעצטע דאַטן: קוועריט פֿאַר רעקאָרדס באשאפן אין די לעצטע 24 שעה צו פאַרזיכערן אַז דער באַקאַפּ איז נישט אַלט.
3. רעפערענציעלע אינטעגריטעט: לויפט סקריפּטן צו טשעקן פֿאַר פאַרלאָזטע פרעמדע שליסלען (orphaned foreign keys), וואָס ווייזן אויף לאָגישע קאָרופּציע.

מאָניטאָרינג און אַלאַרמינג פֿאַר באַקאַפּ-אַנאָמאַליעס

דעטעקטירן קאָרופּציע איידער אַ קאַטאַסטראָפע פּאַסירט פאָדערט שטאַרקע אָבסערוואַביליטי. חוץ בינאַרישע הצלחה/דורכפאַל צושטאַנדן, זאָלט איר מאָניטאָרן די מעטאַדאַטן פון אייערע באַקאַפּ-אַרבעט צו דעטעקטירן אַנאָמאַליעס.

העוריסטישע מאָניטאָרינג

אינטעגרירט אייערע באַקאַפּ-מעטאַדאַטן אין Prometheus און וויזואַליזירט עס מיט Grafana. שטעלט אַרויף אַלאַרמס פֿאַר די פאלגענדע העוריסטיקס:
* פּלוצעמדיקע גרייס-פאַלן: אויב אייער טעגלעכער באַקאַפּ איז קאָנסיסטענט 500GB, און היינטיקער באַקאַפּ איז 50MB, קען די אַרבעט זיין מצליח (Exit Code 0), אָבער עס האָט מסתּמא באַקאַפּט אַ ליידיקן סכעמע.
* דויער-אַנאָמאַליעס: אויב אַ באַקאַפּ וואָס נעמט נאָרמאַל 2 שעה ענדיקט זיך אין 5 מינוט, איז עפּעס איבערגעהיפּערט געוואָרן. פאַרקערט, אויב עס נעמט 10 שעה, קען זיין אַז איר האָט דיסק I/O דעגראַדאַציע וואָס קען פירן צו קאָרופּציע.
* WAL/Archive Log אַקיומיאַליישאַן: אויב אייער דאַטאַבייס דזשענערייט Write-Ahead Logs (WAL) אָבער די באַקאַפּ-סיסטעם אַרכיווירט זיי נישט שנעל גענוג, ריזיקירט איר אַ לאָך אין אייער Point-in-Time Recovery (PITR) קייט.

אימפּלעמענטירן די 3-2-1 הערש מיט אינטעגריטעט-טשעקס

די אינדוסטריע-סטאַנדאַרט 3-2-1 באַקאַפּ-הערש (3 קאָפּיעס פון דאַטן, 2 פאַרשידענע מידיע, 1 אַרויס פון אָרט) איז בלויז עפעקטיוו אויב אַלע קאָפּיעס זענען וועריפיצירט.

דאָ איז וווּ ניצן אַן ענטערפּרייז-לייזונג ווי CloudSave רעדוסירט דראַסטיש די אָפּעראַציע-לאַסט. אַנשטאָט שרייבן און האַלטן קאָמפּלעקסע bash סקריפּטן פֿאַר יעדער דאַטאַבייס-נאָד, אינטעגרירט CloudSave גלייך מיט אייער אינפראַסטרוקטור צו אָטאַמאַטיזירן דעם 3-2-1 לעבנסציקל. עס גיט אומפאַרענדערלעכע סטאָרידזש (immutable storage)—וואָס באַשיצט קעגן ראַנסאָמווער—און פֿעיִקייטן געבויטע, אָטאַמאַטיזירטע רעסטאָר-וועריפיקאַציע-פּלאַנעווען. CloudSave קען אויטאָמאַטיש שטעלן אַרויף אפגעזונדערטע סאַנדבאָקס-סביבות, מאַונטן דעם באַקאַפּ, לויפן אייערע קאַסטאָם SQL וואַלידאַציע-סקריפּטן, און באַריכטן דעם געזונט-צושטאַנד צוריק צו אייער צענטראַלער דאַשבאָרד.

מסקנא

פאַרדאָרבענע דאַטאַבייס-באַקאַפּס זענען אַ שטילער מערדער וואָס קען צעשטערן געשעפטן. זיך פאַרלאָזן בלויז אויף דעם Exit Code 0 פון אַ באַקאַפּ-סקריפּט איז אַ געפערלעכער גאַמבל.

כדי טאַקע באַשיצן אייערע פּראָדוקציע-סביבות, מוזט איר אַדאָפּטירן אַ סטראַטעגיע פון טיפע פאַרטיידיקונג:
1. ענייבלט בלאַט-מדרגה טשעקסומס אין אייער דאַטאַבייס-ענדזשין.
2. נוצט געבוירענע וועריפיקאַציע-געצייג (pg_verifybackup, RESTORE VERIFYONLY) גלייך נאָך באַקאַפּ-שאַפונג.
3. מאָניטאָרט באַקאַפּ-מעטאַדאַטן (גרייס, דויער) פֿאַר העוריסטישע אַנאָמאַליעס.
4. אימפּלעמענטירט אָטאַמאַטיזירטע, עפעמערע רעסטאָר-טעסטינג ווי אַ טייל פון אייער טעגלעכער אָפּעראַציע-פּייפּליין.

דורך זיך טוישן פון אַ פּאַסיווער “פייער און פאַרגעס” באַקאַפּ-מענטאַליטעט צו אַן אַקטיווער “קאָנטינוואָוס רעסטאָר וואַלידיישאַן” מאָדעל, פאַרזיכערט איר אַז ווען אַ קאַטאַסטראָפע פּאַסירט אומפאַרמיידלעך, זענען אייערע דאַטן גרייט, פאַרלאָזלעך, און גאָר רעסטאָרירבאַר.

Categories