93 lines
4.5 KiB
Markdown
93 lines
4.5 KiB
Markdown
# Disaster Recovery Plan
|
|
|
|
This document outlines the procedures to restore critical services in the event of a catastrophic failure. The primary backup mechanism is **ArchiveForge**, which stores compressed `tar.gz` archives of service data on the NAS at `192.168.1.251`.
|
|
|
|
## Guiding Principles
|
|
|
|
* **Prioritize Critical Services**: Restore essential services first (e.g., Traefik, Authelia, ArchiveForge), followed by high-priority applications.
|
|
* **Assume Total Loss**: This plan assumes the primary application host (`192.168.1.252`) is unrecoverable and a new host is being provisioned.
|
|
* **Test Regularly**: This plan should be tested quarterly to ensure its effectiveness.
|
|
|
|
## Phase 1: Infrastructure Restoration
|
|
|
|
This phase focuses on bringing the core infrastructure back online on a new host.
|
|
|
|
1. **Provision New Host**:
|
|
* Install a fresh OS (e.g., Ubuntu Server).
|
|
* Install Docker and Docker Compose.
|
|
* Configure networking to match the old host's static IP (`192.168.1.252`).
|
|
|
|
2. **Mount External Storage**:
|
|
* Mount the NAS storage to the new host. Ensure the mount points are identical to the previous setup (e.g., `/volume1/Media`, `/volume1/docker/backup`).
|
|
* Verify read/write access.
|
|
|
|
3. **Restore Core Services**:
|
|
* **Traefik**: Restore the Traefik configuration from its backup location (if not part of `appdata`) or from a backup. Start Traefik.
|
|
* **Authelia**: Restore the Authelia configuration and start the service.
|
|
* **ArchiveForge**: Restore the ArchiveForge service. This is critical for restoring other applications.
|
|
|
|
## Phase 2: Application Service Restoration
|
|
|
|
This phase details the process of restoring individual application services from the ArchiveForge backups.
|
|
|
|
### General Restoration Steps
|
|
|
|
The general process for restoring a service from an ArchiveForge backup is as follows:
|
|
|
|
1. **Identify the Latest Backup**: Locate the most recent backup for the desired service in the `ArchiveForge` backup directory on the NAS (e.g., `/volume1/docker/backup/ArchiveForge/daily/...`).
|
|
2. **Stop the Service**: If the service is running (e.g., with a fresh but empty configuration), stop it:
|
|
```bash
|
|
cd /mnt/docker-storage/appdata/[service-name]
|
|
docker-compose down
|
|
```
|
|
3. **Restore the Data**: Extract the backup archive into the service's `appdata` directory. This will overwrite the existing configuration and data.
|
|
```bash
|
|
tar -xzf /path/to/backup/[service-name]-YYYYMMDD-HHMMSS.tar.gz -C /mnt/docker-storage/appdata/[service-name]
|
|
```
|
|
4. **Verify Permissions**: Ensure the restored files have the correct ownership and permissions. This is especially important if the `PUID` and `PGID` are used in the `docker-compose.yml`.
|
|
5. **Start the Service**:
|
|
```bash
|
|
cd /mnt/docker-storage/appdata/[service-name]
|
|
docker-compose up -d
|
|
```
|
|
6. **Verify Functionality**: Check the container logs and access the service's web UI to ensure it's running correctly and the data has been restored.
|
|
|
|
### Example: Restoring Readarr
|
|
|
|
1. **Locate Backup**: Find the latest `readarr` backup on the NAS.
|
|
2. **Stop Readarr**:
|
|
```bash
|
|
cd /mnt/docker-storage/appdata/readarr
|
|
docker-compose down
|
|
```
|
|
3. **Restore Data**:
|
|
```bash
|
|
# Example path, replace with actual backup file
|
|
tar -xzf /volume1/docker/backup/ArchiveForge/daily/2025-12-09/readarr-20251209-020000.tar.gz -C /mnt/docker-storage/appdata/readarr
|
|
```
|
|
4. **Start and Verify**:
|
|
```bash
|
|
docker-compose up -d
|
|
docker-compose logs -f
|
|
```
|
|
Access `https://readarr.3ddbrewery.com` to confirm your library and settings are restored.
|
|
|
|
## Phase 3: External Database Restoration
|
|
|
|
For services that use the external database on the NAS (`192.168.1.251`), a separate restoration procedure is required. This procedure depends on how that database is backed up (e.g., `mysqldump` snapshots).
|
|
|
|
**This section needs to be completed once the backup strategy for the external database is fully documented.**
|
|
|
|
1. **Identify Backup**: Locate the latest SQL dump file.
|
|
2. **Restore Dump**: Use the appropriate database command to restore the backup.
|
|
```sql
|
|
-- For MySQL/MariaDB
|
|
mysql -u [username] -p [database_name] < /path/to/backup.sql
|
|
|
|
-- For PostgreSQL
|
|
psql -U [username] -d [database_name] -f /path/to/backup.sql
|
|
```
|
|
3. **Verify**: Check the database to ensure the data has been restored correctly.
|
|
|
|
---
|
|
**Next Review**: This document should be reviewed and updated quarterly, or whenever there is a significant change to the infrastructure.
|