Ehtiyat nüsxənin zədələnməsi zamanı nə etmək lazımdır

Sheet happens. Keçən mühazirədə biz həmçinin verilənlər bazasının tam bərpası üçün addım-addım prosesi öyrəndik. Amma reallıq həmişə sürprizlər hazırlayır. Bəs ehtiyat nüsxən zədələnibsə nə etməlisən? İndi bu məsələni aydınlaşdırmağın vaxtıdır.

CV-ni harada yerləşdirmək daha yaxşıdır?

Zarafat. İndi texniki məsələlərə baxacağıq. Amma unutma ki, hər zarafatda bir az zarafat var :)

Ehtiyat nüsxənin zədələnməsinin analizi

Zədələnmiş ehtiyat nüsxə — bu, diplom işinin faylı kimi bir şeydir ki, təhvil verməzdən əvvəl açılmır. Onun simptomları belədir:

• Bərpa zamanı səhvlər: pg_restore işlədərkən belə səhvlər görə bilərsən:

  pg_restore: [archiver] input file does not appear to be a valid archive

• Bəzi məlumatlar yoxdur və ya faylın ölçüsü səhvdir (məsələn, qəfil çox kiçik və ya sıfıra bərabərdir).
• SQL faylını açanda məlumatlar yarımçıq olur, qəribə simvollar və ya boş hissələr var.

Backup-ların zədələnməsi bir çox səbəbdən baş verə bilər:

• Ehtiyat nüsxə prosesinin yarımçıq qalması (məsələn, elektrik kəsilməsi və ya sistemin söndürülməsi).
• Faylın düzgün ötürülməməsi (flashkarta və ya şəbəkə ilə köçürüləndə səhvlər).
• Avadanlıq problemləri (disklər, RAM, RAID-də nasazlıq).
• Ehtiyat nüsxə üçün sistem və ya utilit ayarlarında səhvlər.
• Viruslar, zərərli proqramlar və əlbəttə ki, təsadüfi "yanlış klik".

Zədələnmiş nüsxədən məlumatların bərpası

Əgər fayl zədələnibsə, bu son deyil. Bəzən nəyisə bərpa etmək mümkündür. Gəlin bir neçə yanaşmaya baxaq.

pg_restore ilə bərpa etməyə cəhd

Əgər fayl pg_dump ilə custom və ya directory formatında yaradılıbsa, pg_restore komandasını --ignore-errors flag-ı ilə işlətməyə cəhd et. Komanda nümunəsi:

pg_restore --dbname=your_database --ignore-errors backup_file.dump

Bu flag utilitəyə deyir ki, bərpa zamanı səhvləri ötür və davam etsin. Təbii ki, zədələnmiş yerlərdə məlumatlar itəcək, amma heç olmasa bir hissəsini bərpa etmək olar.

Əgər bu işləyirsə, bərpa bitəndən sonra məlumatları diqqətlə yoxla və nə çatışmır qeyd et.

Qismən məlumatlardan istifadə

Tutaq ki, ehtiyat nüsxən SQL mətn formatındadır. Onu mətn redaktoru ilə açmağa cəhd et (mümkünsə, Visual Studio Code və ya Notepad++ kimi bir şeylə), harada yarımçıq qaldığını görmək üçün. Əgər fayl oxunur və SQL sorğularının çoxu salamatdırsa:

1. Zədələnmiş hissəni sil.
2. Qalan SQL sorğularını əl ilə və ya psql komandası ilə icra et:

psql -U username -d database_name -f partial_backup.sql

custom formatlı faylı oxumaq

Ehtiyat nüsxən custom formatındadırsa, onun tərkibini hissə-hissə çıxarmağa cəhd edə bilərsən:

pg_restore --list backup_file.dump > file_list.txt

Bu komanda backup-dakı bütün obyektlərin siyahısını yaradacaq. Sonra isə ayrı-ayrı elementləri (məsələn, cədvəllər və ya sxemlər) bərpa etməyə cəhd edə bilərsən:

pg_restore --dbname=your_database --use-list=file_list.txt backup_file.dump

file_list.txt-i redaktə edərək, zədələnmiş elementləri bərpadan çıxara bilərsən.

Arxiv logları (WAL) ilə bərpa etməyə cəhd

Əgər inkremental və ya differensial backup-lardan istifadə edirsənsə (məsələn, pg_basebackup ilə), çox güman ki, arxiv logların (WAL faylları) var. Onlar əvvəlki backup-dan bəri baş verən bütün dəyişiklikləri saxlayır. Məlumatları bərpa etmək üçün:

1. Ən son salamat ehtiyat nüsxəni tap (məsələn, tam backup).
2. PostgreSQL-ə WAL fayllarının harada olduğunu göstər:

   restore_command = 'cp /path/to/wal_directory/%f %p'

3. Bərpanı icra et.

Üçüncü tərəf alətlərindən istifadə

Bəzən faylların bərpası üçün utilitlərdən istifadə etməklə backup zədələnməsini minimuma endirmək olar. Populyar alətlərdən biri ddrescue-dir. Komanda nümunəsi:

ddrescue --force backup_file.dump recovered_dump.file

Bu utilit mümkün qədər çox məlumatı bərpa etməyə və faylın yeni surətini yaratmağa çalışacaq.

Ehtiyat nüsxələrin zədələnməsinin qarşısını almaq

Bəli, zədələnmiş fayllarla işləmək streslidir. Gəlin belə situasiyalardan necə qaçmaq olar, düşünək.

Kopyaları bir neçə yerdə saxlamaq

Backup layihəsində həmişə belə bir qayda var: "yumurtaları bir səbətə qoyma". Backup-larını dublikat et:

• Lokal serverdə.
• Buludda (Amazon S3, Google Cloud Storage və ya hətta Dropbox kimi sadə servislərdə).
• Xarici daşıyıcılarda (əgər super-qorunmaq istəyirsənsə).

Ehtiyat nüsxələrin müntəzəm yoxlanması

IT dünyasında belə bir deyim var: "Test olunmayan backup — backup deyil". Backup-larını müntəzəm yoxla, test bərpası et. Bunun üçün:

1. Backup-u test serverə yüklə.
2. Ondan məlumatları bərpa et.
3. Düzgünlüyünü yoxla.

Kontrol summalardan istifadə

Ehtiyat nüsxə yaradanda faylların kontrol summasını generasiya et (məsələn, MD5 və ya SHA256 alqoritmləri ilə):

md5sum backup_file.dump > backup_file.md5

Bərpa zamanı cari kontrol summanı orijinal ilə müqayisə et:

md5sum -c backup_file.md5

Beləliklə, faylın zədələnməsini əvvəlcədən biləcəksən.

Zədələnmiş nüsxələrdən bərpa nümunələri

Gəlin bir neçə real case-ə baxaq.

Case 1. Fayl köçürülməsi zamanı səhv

Backup-u FTP ilə köçürürsən, amma birdən görürsən ki, fayl gözləniləndən kiçikdir. pg_dump ilə mətn formatında backup etmisən, ona görə də:

1. Faylı redaktorda açdın.
2. Zədələnmiş hissəni sildin.
3. Faylın işlək hissəsini psql ilə bərpa etdin.

Case 2. WAL-da qismən məlumat itkisi

Serverin inkremental backup və arxiv WAL fayllarından istifadə edirdi. Birdən bəzi fayllar yox oldu. Amma pg_basebackup və qalan WAL faylları ilə, onların yolunu bərpa ayarlarında göstərməklə məlumatları bərpa edə bildin.

Unutma, backup — təkcə kopya yaratmaq deyil, həm də onları yoxlamaqdır. Qiyaməti gözləmə ki, backup-larının faydasız olduğunu başa düşəsən. Əgər nüsxə zədələnibsə, panik etmə: PostgreSQL məlumatlarını geri qaytarmaq üçün bir çox yol verir. Əsas odur ki, tez və diqqətlə hərəkət et!

Yox, heç nə kömək etmədisə — bu mühazirənin birinci bəndini yenidən oxu.