54 lines
1.6 KiB
Markdown
54 lines
1.6 KiB
Markdown
## ✅ **Point 4 – Storage – FINAL**
|
||
|
||
### **Role**
|
||
|
||
* Defines how production and backup data is stored, protected, and accessed in the homelab
|
||
* Focuses on NAS devices (TerraMaster, Synology), backup flows, and operational rules
|
||
|
||
---
|
||
|
||
### **NAS device roles**
|
||
|
||
* **TerraMaster**: primary production data store
|
||
* **Synology**: backup target for TerraMaster, staging for offsite/cloud
|
||
* Both: never run compute workloads or join Swarm
|
||
|
||
---
|
||
|
||
### **Data flows**
|
||
|
||
* Production data written to TerraMaster
|
||
* Rsync from TerraMaster to Synology runs multiple times daily (staged for noon, repeats until 11pm)
|
||
* Synology uploads to cloud via daily cloud sync task
|
||
* VM/container data: backed up via app-level exports or VM snapshots (optional/TBD)
|
||
|
||
---
|
||
|
||
### **Backup policy**
|
||
|
||
* Minimum: daily local backup (TerraMaster → Synology), daily offsite (Synology → cloud)
|
||
* Retention: at least 30 days for critical data
|
||
* Verification: periodic restore tests (cadence TBD)
|
||
|
||
---
|
||
|
||
### **Operational constraints / "never do this"**
|
||
|
||
* Never run Docker/Swarm workloads on NAS
|
||
* Never use NAS as a dependency for Swarm control-plane health
|
||
* Never skip scheduled backups without explicit, documented exception
|
||
|
||
---
|
||
|
||
### **Expansion and change model**
|
||
|
||
* Add new storage only by explicit design update
|
||
* Changes to backup cadence, retention, or offsite policy require contract update
|
||
|
||
---
|
||
|
||
### **Further considerations**
|
||
|
||
* Exact backup scripts, schedules, and cloud provider details will live in a separate, detailed storage/backup doc (to be referenced here)
|
||
* Storage contract should be reviewed at least annually or after major infra changes
|