Repository navigation
docs: document the verified volume backup and restore procedure - #36
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refs #22 (the issue asks for the volume backup/restore to be documented; the soak and the rollback drill still have to happen, so this does not close it).
New: a proper backup section (what the volume is, cold vs hot copy, with the manifest verification that makes a hot copy trustworthy, and how to keep a copy outside the container) and a restore section.
The restore section is not written from memory: it was exercised on the production container. A backup was taken, extracted into a scratch directory, ownership restored and hashed, and then a second davcloud instance was started on another port over the restored copy to see the data served before touching anything live. The manifest of the restored copy matches the original volume byte for byte.
Two traps are written down because they cost real time:
sortcollation changes between locales (compare manifests withLC_ALL=Con both sides, otherwise you chase a difference that is not there), and a PROPFIND with an unknownX-Remote-Userbootstraps that user's empty collections, which changes the manifest you are comparing.The one step not exercised yet is replacing the live volume; the doc says so explicitly instead of implying it is tested.