From 545d31f184cd405eeacf4b6f035d9b6ddbdee6bd Mon Sep 17 00:00:00 2001 From: anarcat Date: Wed, 19 Jun 2024 01:46:13 -0400 Subject: [PATCH] docs: clarify backup requirements for storage (#14297) * clarify backup requirements for storage After reading this (again) recently, I was under the impression that our backup strategy ("just throw Bacula at it") was just not good enough and that our backups were inconsistent. I filed [an issue internally][41627] about this because of that concern. But reading a conversation with @SuperQ on IRC, I came under the impression that only the WAL files would be lost. This is an attempt at documenting this more clearly. [41627]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41627 --------- Signed-off-by: anarcat Co-authored-by: Ben Kochie --- docs/storage.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/docs/storage.md b/docs/storage.md index b66f2062a..947960fe1 100644 --- a/docs/storage.md +++ b/docs/storage.md @@ -61,8 +61,11 @@ A Prometheus server's data directory looks something like this: Note that a limitation of local storage is that it is not clustered or replicated. Thus, it is not arbitrarily scalable or durable in the face of drive or node outages and should be managed like any other single node -database. The use of RAID is suggested for storage availability, and -[snapshots](querying/api.md#snapshot) are recommended for backups. With proper +database. + +[Snapshots](querying/api.md#snapshot) are recommended for backups. Backups +made without snapshots run the risk of losing data that was recorded since +the last WAL sync, which typically happens every two hours. With proper architecture, it is possible to retain years of data in local storage. Alternatively, external storage may be used via the