---
title: "ಬ್ಯಾಕಪ್, ಸಮಯದ ಮೊದಲು ಚೇತರಿಕೆ ಮತ್ತು ಮರುಸ್ಥಾಪನಾ ಡ್ರಿಲ್"
description: "Quire ಬ್ಯಾಕಪ್ ಮಾಡಿ, ಅದನ್ನು ಒಂದು ಸಮಯಬಿಂದುವಿಗೆ ಮರುಸ್ಥಾಪಿಸಿ, ಮತ್ತು ಮರುಸ್ಥಾಪನಾ ಡ್ರಿಲ್‌ನೊಂದಿಗೆ ಅದನ್ನು ಸಾಬೀತುಪಡಿಸಿ."
image: "https://docs.quirelms.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/kn/llms.txt
> Use this file to discover all available pages before exploring further.

# ಬ್ಯಾಕಪ್, ಸಮಯದ ಮೊದಲು ಚೇತರಿಕೆ ಮತ್ತು ಮರುಸ್ಥಾಪನಾ ಡ್ರಿಲ್

<span id="backup-point-in-time-recovery-and-the-restore-drill"></span>

ವಿನ್ಯಾಸವು `docs/architecture/23-ops.md` ವಿಭಾಗ 8. ಇದು Docker Compose ಉತ್ಪನ್ನಕ್ಕಾಗಿನ
ರನ್‌ಬುಕ್. ಅದನ್ನು ಬರೆಯದ ಒಬ್ಬರು ಅನುಸರಿಸುವಂತೆ ಬರೆಯಲ್ಪಟ್ಟಿದೆ; ಒಂದು ಹಂತ ಅಸ್ಪಷ್ಟವಾಗಿದ್ದರೆ,
ಅದು ಈ ದಸ್ತಾವೇಜಿನ ದೋಷ.

## ಏನು ರಕ್ಷಿಸಲ್ಪಟ್ಟಿದೆ, ಮತ್ತು ಹೇಗೆ <!--quire:what-is-protected-and-how-->

| ಸಂಪನ್ಮೂಲ | ಹೇಗೆ | ಎಲ್ಲಿ |
| --- | --- | --- |
| ಡೇಟಾಬೇಸ್ | WAL ನಿರಂತರವಾಗಿ ಆರ್ಕೈವ್ ಆಗುತ್ತದೆ, ಗರಿಷ್ಠ ಪ್ರತಿ 60 ಸೆಕೆಂಡ್‌ಗೊಮ್ಮೆ, ಮೊದಲ ಬೂಟ್‌ನಿಂದ | `pgwal` ವಾಲ್ಯೂಮ್ |
| ಡೇಟಾಬೇಸ್ | `pg_basebackup` ನೊಂದಿಗೆ ಮೂಲ ಬ್ಯಾಕಪ್‌ಗಳು, ಡೀಫಾಲ್ಟ್ ಆಗಿ ದೈನಂದಿನ (`backup-scheduler`) | `pgbackup` ವಾಲ್ಯೂಮ್ |
| ಡೇಟಾಬೇಸ್ | ಮೂಲ ಬ್ಯಾಕಪ್‌ಗಳ ಮತ್ತು WAL ನ ಎನ್‌ಕ್ರಿಪ್ಟ್ ನಕಲುಗಳು, ಪ್ರತಿ ಐದು ನಿಮಿಷಕ್ಕೊಮ್ಮೆ (`backup-offsite`) | ನೀವು ಹೆಸರಿಸುವ ಪ್ರತ್ಯೇಕ ಅಂಗಡಿ |
| ಫೈಲ್‌ಗಳು | `files` ವಾಲ್ಯೂಮ್. ನಿಮ್ಮ ಹೋಸ್ಟ್‌ನ ಬ್ಯಾಕಪ್ ಸಾಧನದೊಂದಿಗೆ ಅದನ್ನು ನಕಲಿಸಿ, ಅಥವಾ ಆವೃತ್ತಿ-ಹೊಂದಿರುವ ವಸ್ತು ಸಂಗ್ರಹಣೆ ಬಳಸಿ | `files` ವಾಲ್ಯೂಮ್ |
| ರಹಸ್ಯಗಳು | `docker/.env`, ಎಲ್ಲಕ್ಕಿಂತ ಮೊದಲು `QUIRE_MASTER_KEY` (ಮತ್ತು ಇನ್ನೂ ಬಳಕೆಯಲ್ಲಿರುವ ಯಾವುದೇ `QUIRE_MASTER_KEY_RETIRED`), `QUIRE_BACKUP_ENCRYPTION_KEY`, ಮತ್ತು `docker/secrets/audit-signing-key.pem` | ಒಂದು ನಕಲನ್ನು ಈ ಹೋಸ್ಟ್‌ನಿಂದ ಹೊರಗೆ ಇಡಿ |
| ಹುಡುಕಾಟ ಸೂಚಿಗಳು, ಕ್ಯಾಶ್‌ಗಳು, ರೆಂಡಿಶನ್‌ಗಳು | ಬ್ಯಾಕಪ್ ಅಲ್ಲ; ಮತ್ತೆ ನಿರ್ಮಿಸಲಾಗುತ್ತದೆ | |

ಗುರಿಗಳು: ವೈಫಲ್ಯದ 60 ಸೆಕೆಂಡ್‌ಗಳೊಳಗಿನ ಒಂದು ಚೇತರಿಕೆ ಬಿಂದು, ಮತ್ತು 500 GB ಡೇಟಾಬೇಸ್‌ಗೆ
60 ನಿಮಿಷಗಳೊಳಗೆ ಒಂದು ಮರುಸ್ಥಾಪನೆ.

ಎರಡು ತಪ್ಪುಗಳು ಸಾಮಾನ್ಯ. **ಅದರ ಫೈಲ್‌ಗಳಿಲ್ಲದೆ** ಮರುಸ್ಥಾಪಿಸಲಾದ ಡೇಟಾಬೇಸ್ ಹಾನಿಗೊಂಡ ಪುಟಗಳನ್ನು
ತೋರಿಸುತ್ತದೆ. **`QUIRE_MASTER_KEY` ಇಲ್ಲದೆ** ಮರುಸ್ಥಾಪಿಸಲಾದ ಡೇಟಾಬೇಸ್ ಅದು ಹೊಂದಿರುವ SSO,
webhook ಮತ್ತು ಏಕೀಕರಣ ಪರಿಚಯಪತ್ರಗಳನ್ನು ಡಿಕ್ರಿಪ್ಟ್ ಮಾಡಲಾಗದು; ಮಾಸ್ಟರ್ ಕೀ ರೊಟೇಶನ್ ಏನೂ
ಬಗೆಹರಿಯದಿರುವುದೊಂದಿಗೆ ಮುಗಿಯುವವರೆಗೆ ([key-rotation.md](/kn/ops/key-rotation/)), ಅದು
ನಿವೃತ್ತ ಕೀಗಳನ್ನೂ ಒಳಗೊಂಡಿರುತ್ತದೆ. ಎರಡೂ ಬ್ಯಾಕಪ್‌ನ ಭಾಗ.

## ಬ್ಯಾಕಪ್ ತೆಗೆಯುವುದು <!--quire:taking-backups-->

ಇಡೀ ಕ್ಲಸ್ಟರ್‌ನ ಒಂದು ಮೂಲ ಬ್ಯಾಕಪ್:

```sh
docker compose -f docker/compose.yaml --profile backup run --rm backup
```

ಅದು ಅತಿ ಹೊಸ `QUIRE_BACKUP_KEEP` ಮೂಲ ಬ್ಯಾಕಪ್‌ಗಳನ್ನು (ಡೀಫಾಲ್ಟ್ 5) ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು
ಅತಿ ಹಳೆಯದಕ್ಕೆ ಇನ್ನು ಬೇಕಿಲ್ಲದ WAL ಕತ್ತರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಆರ್ಕೈವ್ ಅನಂತವಾಗಿ ಬೆಳೆಯಲಾಗದು.
ಹೋಸ್ಟ್‌ನಲ್ಲಿ cron ಅಥವಾ ಒಂದು systemd ಟೈಮರ್‌ನೊಂದಿಗೆ ಅದನ್ನು ದೈನಂದಿನವಾಗಿ ವೇಳಾಪಟ್ಟಿ ಮಾಡಿ:

```cron
15 2 * * * cd /srv/quire && docker compose -f docker/compose.yaml --profile backup run --rm backup >> /var/log/quire-backup.log 2>&1
```

ಅಥವಾ ಸ್ಟ್ಯಾಕ್‌ಗೆ ಅದನ್ನು ವೇಳಾಪಟ್ಟಿ ಮಾಡಲು ಬಿಡಿ: `backup` profile `backup-scheduler` ಚಲಾಯಿಸುತ್ತದೆ,
ಅದು ಪ್ರತಿ `QUIRE_BACKUP_INTERVAL_HOURS` (ಡೀಫಾಲ್ಟ್ 24) ಗೆ ಒಂದು ಮೂಲ ಬ್ಯಾಕಪ್ ತೆಗೆಯುತ್ತದೆ,
ಮತ್ತು `backup-offsite`, ಮುಂದೆ ವಿವರಿಸಲ್ಪಟ್ಟಂತೆ.

```sh
docker compose -f docker/compose.yaml --profile backup up -d
```

## ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆದ ಹೋಸ್ಟ್-ಹೊರಗಿನ ನಕಲುಗಳು <!--quire:encrypted-off-host-copies-->

ಎರಡೂ ವಾಲ್ಯೂಮ್‌ಗಳೂ ಡೇಟಾಬೇಸ್‌ನೊಂದೇ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಇರುತ್ತವೆ, ಮತ್ತು ವೈಫಲ್ಯಗೊಂಡ ಯಂತ್ರದಲ್ಲಿನ
ಬ್ಯಾಕಪ್ ಬ್ಯಾಕಪ್ ಅಲ್ಲ. `backup-offsite` ಪ್ರತಿ ಮೂಲ ಬ್ಯಾಕಪ್ ಮತ್ತು ಪ್ರತಿ ಆರ್ಕೈವ್ ಆದ WAL
ವಿಭಾಗವನ್ನು ಸಂಗ್ರಹಣಾ ಪೋರ್ಟ್ ಮೂಲಕ ಪ್ರತ್ಯೇಕ ಅಂಗಡಿಗೆ, ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿ, ನಂತರ ಉಳಿಸುವಿಕೆಯ
ಅಡಿಯಲ್ಲಿ ಅಲ್ಲಿ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ:

- **ಎನ್‌ಕ್ರಿಪ್ಶನ್.** `QUIRE_BACKUP_ENCRYPTION_KEY` (ಅಥವಾ
  `QUIRE_BACKUP_ENCRYPTION_KEY_FILE` ಹೆಸರಿಸಿದ ಫೈಲ್) ನೊಂದಿಗೆ AES-256-GCM: 32 ಬೈಟ್‌ಗಳು,
  `openssl rand -hex 32` ನಿಂದ. ಪ್ರತಿ ಫೈಲ್‌ಗೂ ತನ್ನದೇ nonce ಮತ್ತು ಒಂದು ದೃಢೀಕರಣ ಟ್ಯಾಗ್
  ಇರುತ್ತದೆ, ಆದ್ದರಿಂದ ಕೀ ಇಲ್ಲದೆ ಒಂದು ನಕಲು ಓದಲಾಗದು ಮತ್ತು ಅದರ ಯಾವುದೇ ಬದಲಾವಣೆ
  ಪತ್ತೆಯಾಗುತ್ತದೆ. ಕೀಯನ್ನು `QUIRE_MASTER_KEY` ಜೊತೆಗೆ, ಈ ಹೋಸ್ಟ್‌ನಿಂದ ದೂರ ಮತ್ತು
  ಬ್ಯಾಕಪ್ ಅಂಗಡಿಯಿಂದ ದೂರ ಇಡಿ. ಕೀ ಇಲ್ಲದೆ ಮರುಸ್ಥಾಪನೆ ಇಲ್ಲ.
- **ಎಲ್ಲಿ.** `QUIRE_BACKUP_STORAGE_DRIVER` `s3`, `azure` ಅಥವಾ `local`
  (`QUIRE_BACKUP_STORAGE_ROOT` ನಲ್ಲಿ ಮೌಂಟ್ ಆದ ರಿಮೋಟ್ ಡಿಸ್ಕ್) ಆಗಿದೆ. ಸೆಟ್ಟಿಂಗ್‌ಗಳು
  `QUIRE_BACKUP_` ಪೂರ್ವಪ್ರತ್ಯಯದೊಂದಿಗೆ ಫೈಲ್ ಸಂಗ್ರಹಣಾ ಸೆಟ್ಟಿಂಗ್‌ಗಳೇ:
  `QUIRE_BACKUP_S3_ENDPOINT`, `QUIRE_BACKUP_S3_BUCKET`,
  `QUIRE_BACKUP_S3_ACCESS_KEY_ID`, ಇತ್ಯಾದಿ. ಫೈಲ್‌ಗಳಿಂದ ಬೇರೆ ಬಕೆಟ್ ಮತ್ತು, ಆದ್ಯತೆಯಾಗಿ,
  ಬೇರೆ ಖಾತೆ ಬಳಸಿ, ಪ್ರೊವೈಡರ್ ಅನುಮತಿಸಿದರೆ ಬರೆಯಬಹುದಾದರೂ ಅಳಿಸಲಾಗದ ಪರಿಚಯಪತ್ರಗಳೊಂದಿಗೆ.
- **ಉಳಿಸುವಿಕೆ.** ಅತಿ ಹೊಸ `QUIRE_BACKUP_OFFSITE_KEEP` ಮೂಲ ಬ್ಯಾಕಪ್‌ಗಳು
  (ಡೀಫಾಲ್ಟ್ `QUIRE_BACKUP_KEEP`, ಇಲ್ಲದಿದ್ದರೆ 7) ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಅತಿ ಹಳೆಯದಕ್ಕೆ ಬೇಕಾದ WAL;
  ಹಳೆಯ ಸೆಟ್‌ಗಳು ಮತ್ತು ವಿಭಾಗಗಳನ್ನು ಅಂಗಡಿಯಿಂದ ಅಳಿಸಲಾಗುತ್ತದೆ.
- **ಯಾವಾಗ.** ಪ್ರತಿ `QUIRE_BACKUP_SHIP_INTERVAL_SECONDS` (ಡೀಫಾಲ್ಟ್ 300).
  ಸಾಗಣೆ idempotent: ಈಗಾಗಲೇ ಸಂಗ್ರಹಿಸಲ್ಪಟ್ಟಿದ್ದನ್ನು ಕಳೆದುಬಿಡಲಾಗುತ್ತದೆ, ಮತ್ತು ಒಂದು ಮೂಲ
  ಬ್ಯಾಕಪ್ ಅದರ ಪಟ್ಟಿಪುಸ್ತಕ ಕೊನೆಯದಾಗಿ ಬರೆಯಲ್ಪಡುವವರೆಗೆ ಮಾತ್ರ ಸಂಗ್ರಹಿಸಲ್ಪಟ್ಟಿದೆ ಎಂದು
  ಲೆಕ್ಕಹಾಕಲ್ಪಡುತ್ತದೆ.

ಅದೇ ಆದೇಶವನ್ನು ಕೈಯಾರಿ ಚಲಾಯಿಸಿ:

```sh
docker compose -f docker/compose.yaml run --rm backup-offsite bun apps/worker/src/backups/main.ts ship
docker compose -f docker/compose.yaml run --rm backup-offsite bun apps/worker/src/backups/main.ts verify
```

ಹೊಸ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಮರುಸ್ಥಾಪಿಸಲು, ಮೊದಲು ಒಂದು ಸೆಟ್ ಹಿಂತಿರುಗಿಸಿ, ನಂತರ ಕೆಳಗಿನ ಹಂತಗಳನ್ನು
ಪಡೆದ ಡೈರೆಕ್ಟರಿಯನ್ನು `pgbackup` ವಾಲ್ಯೂಮ್‌ನ ಬದಲಿಗೆ ಮತ್ತು ಪಡೆದ `wal-archive` ಅನ್ನು `pgwal` ನ
ಬದಲಿಗೆ ಇಟ್ಟುಕೊಂಡು ಅನುಸರಿಸಿ:

```sh
bun apps/worker/src/backups/main.ts fetch base-20260924T021500Z /srv/restore
```

## ಒಂದು ಸಮಯಬಿಂದುವಿಗೆ ಮರುಸ್ಥಾಪಿಸುವುದು <!--quire:restoring-to-a-point-in-time-->

ಡೇಟಾ ನಷ್ಟದ ನಂತರ ಇದನ್ನು ಬಳಸಿ: ಕೆಟ್ಟ ಆಮದು, ಅಳಿಸಲಾದ ಕೋರ್ಸ್, ನೀವು ರದ್ದುಗೊಳಿಸಬೇಕಾದ ಒಂದು
ಒಪ್ಪಂದ ವಲಸೆ. ಇದು ಲೈವ್ ಡೇಟಾಬೇಸ್ ಬದಲಾಯಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಮೊದಲು ಕೆಳಗಿನ ಡ್ರಿಲ್‌ನೊಂದಿಗೆ
ಅದನ್ನು ಅಭ್ಯಾಸ ಮಾಡಿ.

1. **ಗುರಿ ಸಮಯ ಆಯ್ಕೆಮಾಡಿ**, UTC ನಲ್ಲಿ, ಹಾನಿಯ ಸರಿಯಾಗಿ ಮೊದಲು:
   `2026-09-24 09:30:00+00`. ಆಡಿಟ್ ಲಾಗ್ (`/admin/audit`) ಸಾಮಾನ್ಯವಾಗಿ ಆ ಕ್ಷಣವನ್ನು
   ತೋರಿಸುತ್ತದೆ.
2. **ಬರೆಯುವ ಎಲ್ಲವನ್ನೂ ನಿಲ್ಲಿಸಿ**:
   `docker compose -f docker/compose.yaml stop web content worker scheduler collab`
3. ಮರುಸ್ಥಾಪನೆ ಪರಿಶೀಲಿಸಲ್ಪಡುವವರೆಗೂ **ಹಾನಿಗೊಂಡ ಕ್ಲಸ್ಟರ್ ಇಟ್ಟುಕೊಳ್ಳಿ**:
   ```sh
   docker compose -f docker/compose.yaml stop postgres
   docker run --rm -v quire_postgres18-data:/from -v quire_postgres-damaged:/to alpine cp -a /from/. /to/
   ```
4. **ಗುರಿಯಿಂದ ಹಳೆಯ ಅತಿ ಹೊಸ ಮೂಲ ಬ್ಯಾಕಪ್** ಡೇಟಾ ವಾಲ್ಯೂಮ್‌ಗೆ ಬಿಡಿಸಿ, ಮತ್ತು ಗುರಿಮಾಡಿದ
   ಚೇತರಿಕೆ ಕೇಳಿ:
   ```sh
   docker run --rm -v quire_pgbackup:/backups:ro -v quire_postgres18-data:/var/lib/postgresql postgres:18-alpine sh -euc '
     base="$(ls -1d /backups/base-* | sort | tail -n 1)"   # or the one before the target
     rm -rf /var/lib/postgresql/18/docker && mkdir -p /var/lib/postgresql/18/docker
     tar -xzf "$base/base.tar.gz" -C /var/lib/postgresql/18/docker
     touch /var/lib/postgresql/18/docker/recovery.signal
     chown -R postgres:postgres /var/lib/postgresql/18/docker && chmod 700 /var/lib/postgresql/18/docker'
   ```
5. **ಚೇತರಿಸಿ**: ಚೇತರಿಕೆ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ Postgres ಒಮ್ಮೆ ಆರಂಭಿಸಿ, ಸಾಮಾನ್ಯ ಫೈಲ್
   ಮುಟ್ಟದಂತೆ ಒಂದು Compose override ನಿಂದ:
   ```yaml
   # docker/compose.recover.yaml
   services:
     postgres:
       command: [postgres, -c, "restore_command=cp /var/lib/postgresql/wal-archive/%f %p",
                 -c, "recovery_target_time=2026-09-24 09:30:00+00",
                 -c, recovery_target_action=promote, -c, archive_mode=off,
                 -c, max_connections=200, -c, hba_file=/etc/postgresql/pg_hba.conf]
   ```
   override ಸಂಪೂರ್ಣ ಆದೇಶವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದು ಚೇತರಿಕೆ ಅವಲಂಬಿಸಿರುವ ಎರಡು
   ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತದೆ: ಪ್ರಾಥಮಿಕದಿಂತ ಕಡಿಮೆ ಇಲ್ಲದ `max_connections`
   (ಇಲ್ಲದಿದ್ದರೆ ಚೇತರಿಕೆ "insufficient parameter settings" ನೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ) ಮತ್ತು
   ಮೌಂಟ್ ಆದ `pg_hba.conf`.
   ```sh
   docker compose -f docker/compose.yaml -f docker/compose.recover.yaml up -d postgres
   docker compose -f docker/compose.yaml logs -f postgres   # wait for "database system is ready"
   ```
6. **ಯಾರನ್ನೂ ಒಳಗೆ ಬಿಡುವ ಮೊದಲು ಅದನ್ನು ಪರಿಶೀಲಿಸಿ**: ಆಡಿಟ್ ಸರಪಳಿ
   (`docker compose -f docker/compose.yaml run --rm worker bun tooling/audit-verify/run.ts`),
   ಮತ್ತು ಕಳೆದುಹೋದ ಡೇಟಾ ಹಿಂತಿರಗಿದೆ ಎಂದು.
7. **ಸಾಮಾನ್ಯತೆಗೆ ಹಿಂತಿರುಗಿ**: `docker compose -f docker/compose.yaml up -d`. ಇದು
   ಆರ್ಕೈವಿಂಗ್ ಆನ್‌ನೊಂದಿಗೆ Postgres ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಮತ್ತು ಒಂದು ಹೊಸ WAL ಟೈಮ್‌ಲೈನ್
   ಆರಂಭವಾಗುತ್ತದೆ. ತಕ್ಷಣವೇ ಒಂದು ಹೊಸ ಮೂಲ ಬ್ಯಾಕಪ್ ತೆಗೆಯಿರಿ.

`quire` ಯೋಜನೆಯ ಹೆಸರು ಪ್ರತಿ ವಾಲ್ಯೂಮ್‌ಗೆ ಪೂರ್ವಪ್ರತ್ಯಯವಾಗಿ ಬರುತ್ತದೆ; `docker volume ls`
ನಿಖರ ಹೆಸರುಗಳನ್ನು ತೋರಿಸುತ್ತದೆ.

## ನಿಗದಿತ ದೃಢೀಕರಣಾ ಡ್ರಿಲ್ <!--quire:the-scheduled-verification-drill-->

`backup-offsite` ಪ್ರತಿ `QUIRE_BACKUP_DRILL_INTERVAL_HOURS` (ಡೀಫಾಲ್ಟ್ 168, ಸಾಪ್ತಾಹಿಕ)
ಗೆ ಒಂದು ಡ್ರಿಲ್ ಚಲಾಯಿಸುತ್ತದೆ, ಮತ್ತು ಒಂದು ವಿಫಲವಾದ ನಂತರ ಮುಂದಿನ ಸುತ್ತಿನಲ್ಲಿ ಮತ್ತೆ.
ಅದು ಅತಿ ಹೊಸ ಹೋಸ್ಟ್-ಹೊರಗಿನ ಮೂಲ ಬ್ಯಾಕಪ್ ಮತ್ತು ಅದರ ನಂತರದ ಪ್ರತಿ WAL ವಿಭಾಗವನ್ನು
ಪಡೆಯುತ್ತದೆ, ಪ್ರತಿಯೊಂದನ್ನೂ ಡಿಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತದೆ (ಕೀ ಇನ್ನೂ ಅವುಗಳನ್ನು ತೆರೆಯುತ್ತದೆ ಮತ್ತು ಏನೂ
ಬದಲಾಯಿಸಲ್ಪಟ್ಟಿಲ್ಲ ಎಂದು ಇದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ), ಪ್ರತಿ ಫೈಲ್ ಅನ್ನು ಅದರ ಪಟ್ಟಿಪುಸ್ತಕದೊಂದಿಗೆ
ಹೋಲಿಸುತ್ತದೆ, ಆರ್ಕೈವ್ ಒಂದು Postgres ಡೇಟಾ ಡೈರೆಕ್ಟರಿ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ, ಮತ್ತು ಬ್ಯಾಕಪ್‌ನಿಂದ
ಮುಂದೆ WAL ನಲ್ಲಿ ಯಾವುದೇ ರಂಧ್ರವಿಲ್ಲ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ. ವರದಿಯನ್ನು
`reports/drill-<time>.json` ಆಗಿ ಅಂಗಡಿಯಲ್ಲಿ ಮತ್ತು ಸೇವೆಯ ಲಾಗ್‌ನಲ್ಲಿ ಬರೆಯಲಾಗುತ್ತದೆ; ವಿಫಲ
ಡ್ರಿಲ್ ಫೈಲ್ ಅಥವಾ ಮೊದಲ ಕಾಣೆಯಾದ ವಿಭಾಗವನ್ನು ಹೆಸರಿಸುತ್ತದೆ.

## ಮರುಸ್ಥಾಪನಾ ಡ್ರಿಲ್ <!--quire:the-restore-drill-->

ಎಂದಿಗೂ ಮರುಸ್ಥಾಪಿಸಲ್ಪಟ್ಟಿರದ ಬ್ಯಾಕಪ್ ಬ್ಯಾಕಪ್ ಅಲ್ಲ. ಡ್ರಿಲ್ ಗುರಿಯ ಮೊದಲು ತೆಗೆಯಲಾದ ಅತಿ ಹೊಸ
ಸಂಪೂರ್ಣ ಮೂಲ ಬ್ಯಾಕಪ್ ಮತ್ತು WAL ಆರ್ಕೈವ್ ಅನ್ನು, ಲೈವ್ ಒಂದರೊಂದಿಗೆ ಏನೂ ಹಂಚಿಕೊಳ್ಳದ ಒಂದು
ಸ್ಕ್ರಾಚ್ Postgres ಗೆ ಮರುಸ್ಥಾಪಿಸುತ್ತದೆ, ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ:

```sh
docker/scripts/restore-drill.sh                                  # to ninety minutes ago
docker/scripts/restore-drill.sh --target "2026-09-24 09:30:00+00"
```

ಗುರಿಯು ನಿಖರವಾಗಿ ಆ ರೂಪದಲ್ಲಿ UTC. ಇದಿಗೆ ಅದಕ್ಕಿಂತ ಹಳೆಯ ಒಂದು ಮೂಲ ಬ್ಯಾಕಪ್ ಮತ್ತು ಅದರ
ಮುಂದೆ ಆರ್ಕೈವ್ ಆದ WAL ಬೇಕು: ಹೊಸ ಸ್ಥಾಪನೆಯಲ್ಲಿ, ಒಂದು ಮೂಲ ಬ್ಯಾಕಪ್ ತೆಗೆದು ಬ್ಯಾಕಪ್‌ನ
ನಂತರದ ಗುರಿ ಆಯ್ಕೆಮಾಡುವ ಮೊದಲು ಮುಂದಿನ ಆರ್ಕೈವ್ ಆದ ವಿಭಾಗಕ್ಕಾಗಿ (ಬರೆಯುವಿಕೆಯೊಂದಿಗೆ ಗರಿಷ್ಠ
ಒಂದು ನಿಮಿಷ) ಕಾಯಿರಿ. ಡ್ರಿಲ್‌ಗೆ ಹೋಸ್ಟ್‌ನಲ್ಲಿ Docker ಮತ್ತು bash ಬೇಕು, ಬೇರೇನೂ ಬೇಡ.

ಪ್ರತಿ ಹಂತವೂ ಡ್ರಿಲ್ ಅನ್ನು ವಿಫಲಗೊಳಿಸುತ್ತದೆ:

1. **ಚೇತರಿಸಬಹುದಿಕೆ**: ಸ್ಕ್ರಾಚ್ ಕ್ಲಸ್ಟರ್ ಗುರಿಯವರೆಗೆ ಮರುಚಲಾಯಿಸಿ ತೆರೆಯುತ್ತದೆ.
2. **ಸಂಪೂರ್ಣತೆ**: ಪ್ರತಿ ಕೋಷ್ಟಕದ ಸಾಲು ಎಣಿಕೆ ಲೈವ್ ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಹೋಲಿಸಿ
   (`tooling/restore-drill`). ಗುರಿಯ ನಂತರ ಲೈವ್ ಡೇಟಾಬೇಸ್ ಮುಂದೆ ಹೋಗಿದೆ, ಆದ್ದರಿಂದ ಒಂದು
   ಕೋಷ್ಟಕವು 500 ಸಾಲುಗಳು ಮತ್ತು ಅದರ ಗಾತ್ರದ ಒಂದರ ಹತ್ತರಷ್ಟು ದೊಡ್ಡದು, ಯಾವ ದಿಕ್ಕಿನಲ್ಲೇ
   ಆಗಲಿ, ವ್ಯತ್ಯಾಸ ಹೊಂದಬಹುದು (ಬರೆಯುವಿಕೆಗಳು ಅದನ್ನು ಹಿಂದೆ ಬೀಳಿಸುತ್ತವೆ, ಅಳಿಸುವಿಕೆಗಳು
   ಮರುಸ್ಥಾಪನೆ ಹೆಚ್ಚು ಹಿಡಿದಿಡುವಂತೆ ಮಾಡುತ್ತವೆ); ಗುರಿಯ ನಂತರ ರಚಿಸಲಾದ ಒಂದು ವಿಭಜಕವು
   ಕಳೆದುಹೋದ ಕೋಷ್ಟಕವಲ್ಲ. ಹೆಚ್ಚು ವ್ಯಸ್ತ ಸ್ಥಾಪನೆಯಲ್ಲಿ `QUIRE_DRILL_MAX_BEHIND` ಮತ್ತು
   `QUIRE_DRILL_MAX_DRIFT_RATIO` ನೊಂದಿಗೆ ಅನುಮತಿ ವಿಸ್ತರಿಸಿ. ಕಾಣೆಯಾದ ಅಥವಾ ಖಾಲಿಯಾದ
   ಕೋಷ್ಟಕ ವಿಫಲವಾಗುತ್ತದೆ.
3. **ಸಮಗ್ರತೆ**: ಆಡಿಟ್ ಹ್ಯಾಶ್ ಸರಪಳಿಯು ಮರುಸ್ಥಾಪಿಸಲಾದ ನಕಲಿನಲ್ಲಿ ಪರಿಶೀಲನೆಯಾಗುತ್ತದೆ.
4. **ಉಪಯೋಗಿಸಬಹುದಿಕೆ**: ಅಪ್ಲಿಕೇಶನ್ ಪಾತ್ರವು ಸಾಲು-ಮಟ್ಟದ ಭದ್ರತೆಯ ಮೂಲಕ ಓದುತ್ತದೆ.
5. **ಸಮಯ**: ಹಸಿರು ಆಗುವವರೆಗೆ ಆರಂಭದಿಂದ, `QUIRE_DRILL_RTO_SECONDS`
   (ಡೀಫಾಲ್ಟ್ 3600) ವಿರುದ್ಧ.

ಇದು ಎಂದಿಗೂ ಲೈವ್ ಡೇಟಾಬೇಸ್ ಅಥವಾ ಅದರ ವಾಲ್ಯೂಮ್‌ಗಳಿಗೆ ಬರೆಯುವುದಿಲ್ಲ: ಬ್ಯಾಕಪ್ ಮತ್ತು WAL
ವಾಲ್ಯೂಮ್‌ಗಳನ್ನು ಓದು-ಮಾತ್ರವಾಗಿ ಮೌಂಟ್ ಮಾಡಲಾಗಿರುತ್ತದೆ ಮತ್ತು ಸ್ಕ್ರಾಚ್ ಕ್ಲಸ್ಟರ್ ಕೊನೆಯಲ್ಲಿ
ತೆಗೆದುಹಾಕಲ್ಪಡುತ್ತದೆ, ಗೆದ್ದರೂ ಸೋತರೂ.

JSON ವರದಿ ಬರೆಯಲ್ಪಡಬೇಕೆಂದಾದರೆ `QUIRE_DRILL_REPORT` ಅನ್ನು ಒಂದು ಮಾರ್ಗಕ್ಕೆ ಹೊಂದಿಸಿ, ಗೆದ್ದರೂ
ಸೋತರೂ, ಮತ್ತು ಅದನ್ನು Docker ಹೋಸ್ಟ್‌ನಲ್ಲಿ ವೇಳಾಪಟ್ಟಿಯೊಂದಿಗೆ ಚಲಾಯಿಸಿ:

```cron
30 3 1 * * cd /srv/quire && QUIRE_DRILL_REPORT=/var/log/quire-drill.json docker/scripts/restore-drill.sh >> /var/log/quire-drill.log 2>&1
```

ಅದನ್ನು ತಿಂಗಳಿಗೊಮ್ಮೆ ಮತ್ತು ಪ್ರತಿ ಅಪ್‌ಗ್ರೇಡ್‌ಗೂ ಮೊದಲು ಚಲಾಯಿಸಿ. ವಿಫಲ ಡ್ರಿಲ್ ಅಪ್‌ಗ್ರೇಡ್ ಅನ್ನು
ತಡೆಯುತ್ತದೆ. ತ್ರೈಮಾಸಿಕವಾಗಿ ಒಮ್ಮೆ, ಈ ರನ್‌ಬುಕ್ ಬರೆಯದ ಒಬ್ಬರಿಗೆ ಬೇರೆ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಕೇವಲ ಈ
ದಸ್ತಾವೇಜು ಬಳಸಿ ನಿಜವಾದ ಒಂದು ಸಮಯಬಿಂದು ಮರುಸ್ಥಾಪನೆ ನಡೆಸಲು ನೀಡಿ.

## ಫೈಲ್‌ಗಳು <!--quire:files-->

ಸ್ಥಳೀಯ ಫೈಲ್‌ಗಳು `files` ವಾಲ್ಯೂಮ್‌ನಲ್ಲಿ ಇರುತ್ತವೆ. ಅದನ್ನು ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ, ಅದೇ ಸಮಯದಲ್ಲಿ,
ಬ್ಯಾಕಪ್ ಮಾಡಿ, ಮತ್ತು ಎರಡನ್ನೂ ಒಟ್ಟಿಗೆ ಮರುಸ್ಥಾಪಿಸಿ:

```sh
docker run --rm -v quire_files:/files:ro -v "$PWD":/out alpine tar -czf /out/files-$(date -u +%Y%m%d).tar.gz -C /files .
```

ವಸ್ತು ಸಂಗ್ರಹಣೆಯೊಂದಿಗೆ, ಬಕೆಟ್ ಆವೃತ್ತಿಕರಣ ಆನ್ ಮಾಡಿ ಮತ್ತು 35 ದಿನಗಳ ಅಪ್ರಚಲಿತ ಆವೃತ್ತಿಗಳನ್ನು
ಇಡಿ; ಫೈಲ್‌ಗಳಿಗೆ ಸಮಯಬಿಂದು ಚೇತರಿಕೆಯು ಆಗ ಬಕೆಟ್‌ನದೇ ಆಗಿರುತ್ತದೆ.

Source: https://docs.quirelms.com/kn/ops/backup-restore/index.mdx