آپ PostgreSQL کا بیک اپ اور بحالی کیسے کرتے ہیں؟

Question

Accepted Answer

PostgreSQL کئی **بیک اپ** طریقے فراہم کرتا ہے — منطقی بیک اپ (`pg_dump`) اور جسمانی بیک اپ (base backup + WAL **point-in-time recovery** کے لیے)۔ ایک مضبوط بیک اپ اور بحالی کی حکمت عملی ڈیٹا کے نقصان سے بچاؤ کے لیے انتہائی ضروری ہے، اور اہم بات یہ ہے کہ **بیک اپ کو ضرور آزمایا جانا چاہیے**۔

## منطقی بیک اپ — pg_dump

```bash
# pg_dump — dumps a database as SQL (or a custom archive) — portable, flexible
pg_dump -U user -d mydb -F c -f backup.dump      # custom format (compressed, flexible restore)
pg_dump -U user -d mydb > backup.sql              # plain SQL
pg_dumpall > all.sql                              # ALL databases + roles

# restore
pg_restore -U user -d mydb backup.dump            # from custom format
psql -U user -d mydb -f backup.sql                # from plain SQL
```

`pg_dump` کسی ڈیٹا بیس کا منطقی بیک اپ (SQL یا archive) بناتا ہے — قابل منتقلی (مختلف ورژن/سرورز میں بحال کرنے کے قابل)، چھوٹے ڈیٹا بیسز، منتقلیوں، اور منتخب بیک اپس کے لیے اچھا۔ لیکن یہ ایک point-in-time snapshot ہے (مسلسل recovery نہیں)۔

## جسمانی بیک اپ + Point-in-Time Recovery (PITR)

```text
For larger/critical databases: a BASE BACKUP (a copy of the data files) + continuous
archiving of the WAL (write-ahead log) → enables POINT-IN-TIME RECOVERY:
  ✓ Restore the base backup, then REPLAY WAL up to ANY point in time
  ✓ Recover to JUST BEFORE a disaster (e.g. an accidental DROP TABLE at 2:47pm)
→ Tools: pg_basebackup, WAL archiving, and tools like pgBackRest / Barman automate this.
```

**PITR** طاقتور ہے: مسلسل WAL کو محفوظ کرنے سے، آپ کسی بھی لمحے کو بحال کر سکتے ہیں — صرف آخری بیک اپ تک محدود نہیں — جو آفات سے ڈیٹا کے نقصان کو کم کرنے کے لیے انتہائی ضروری ہے۔

## بیک اپ کی حکمت عملی کی ضروریات

```text
✓ Regular, AUTOMATED backups (scheduled, not manual/forgotten)
✓ Store backups OFF the database server (and offsite / cloud) — survive hardware failure
✓ Retention policy (keep daily/weekly/monthly as needed)
✓ Combine: periodic base backups + continuous WAL for PITR (critical data)
✓ Backups from a REPLICA to avoid loading the primary
```

## سب سے اہم اصول: اپنے بیک اپس کو آزمائیں

```text
⚠️ A backup you've never restored is NOT a reliable backup.
UNTESTED backups fail when you need them most (corrupt, incomplete, wrong process).
→ Regularly TEST restores to verify they actually work and you know the procedure.
```

## اس کی اہمیت

بیک اپ اور بحالی **نازک** علم ہے PostgreSQL کو ذمہ داری سے چلانے کے لیے — ڈیٹا کے نقصان سے بچاؤ (ہارڈویئر کی خرابی، خرابی، غلط حذف، آفات سے) کسی بھی production ڈیٹا بیس کے لیے سب سے اہم ذمہ داریوں میں سے ایک ہے، لہذا بیک اپ کی حکمت عملی کو سمجھنا انتہائی ضروری سینیئر سطح کا علم ہے۔

طریقوں کو سمجھنا ضروری ہے: **`pg_dump`** (منطقی بیک اپ — قابل منتقلی SQL/archive dumps، چھوٹے ڈیٹا بیسز، منتقلیوں، اور منتخب/cross-version بیک اپس کے لیے اچھے، لیکن صرف point-in-time snapshots) اور **جسمانی بیک اپ Point-in-Time Recovery (PITR) کے ساتھ** (base backup + مسلسل WAL archiving، *کسی بھی* لمحے تک بحالی کو فعال کرتے ہوئے — جو ڈیٹا کے نقصان کو کم کرنے کے لیے طاقتور ہے، جیسے غلط `DROP TABLE` سے پہلے بحال کرنا، اہم ڈیٹا کے لیے ضروری)۔

**حکمت عملی کی ضروریات** کو جاننا (باقاعدہ خودکار بیک اپ، انہیں سرور سے باہر اور دور رکھنا، برقرار رہنے کی پالیسیاں، base backups کو PITR کے لیے WAL کے ساتھ ملانا، replicas سے بیک اپ لینا) اہم operational علم ہے۔

سب سے زیادہ اہم بات، یہ سمجھنا کہ **بیک اپ کو ضرور آزمایا جانا چاہیے** — ایک نہ آزمایا ہوا بیک اپ غیر قابل اعتماد ہے اور اکثر بالکل اسی وقت ناکام ہوتا ہے جب اسے درکار ہو (خرابی، نامکمل ڈیٹا، نامعلوم restore عمل) — یہ ایک اہم، اکثر نظر انداز کیا جانے والا اصول ہے: restores کو باقاعدہ آزمانا وہی ہے جو ایک بیک اپ کی حکمت عملی کو واقعی قابل اعتماد بناتا ہے۔

چونکہ ڈیٹا کا نقصان تباہ کن ہو سکتا ہے (اور بحالی صرف کام کرنے والے بیک اپس کے ذریعے ممکن ہے)، اور چونکہ صحیح حکمت عملی (مناسب بیک اپ طریقے، PITR minimum loss کے لیے، off-site storage، اور انتہائی اہم طور پر *آزمائے ہوئے* restores) وہ ہے جو کسی تنظیم کے ڈیٹا کی حفاظت کرتا ہے، PostgreSQL backup اور recovery کو سمجھنا اہم سینیئر سطح کا علم ہے ذمہ داری سے ڈیٹا بیس کو چلانے کے لیے — ایک high-stakes ذمہ داری جہاں آزمائی ہوئی حکمت عملی اور نہ آزمائی ہوئی کے درمیان فرق آفت سے بحالی اور مستقل ڈیٹا کے نقصان کے درمیان فرق ہو سکتا ہے، اسے ایک ضروری، بار بار متعلقہ موضوع بناتے ہوئے ہر اس شخص کے لیے جو production ڈیٹا بیسز کو چلاتا ہے۔