diff options
| author | Bryan Newbold <bnewbold@robocracy.org> | 2018-08-10 18:50:18 -0700 | 
|---|---|---|
| committer | Bryan Newbold <bnewbold@robocracy.org> | 2018-08-10 18:50:18 -0700 | 
| commit | 10dbda6ce4a793f076115ae49c4ca58acf7d7308 (patch) | |
| tree | 54c527f11cd79264bfe89c16a5431eea449c4da4 /rust | |
| parent | 962717ef3dd5051ded20132275007868de27058c (diff) | |
| download | fatcat-10dbda6ce4a793f076115ae49c4ca58acf7d7308.tar.gz fatcat-10dbda6ce4a793f076115ae49c4ca58acf7d7308.zip | |
rust backups notes
Diffstat (limited to 'rust')
| -rw-r--r-- | rust/README.md | 30 | 
1 files changed, 30 insertions, 0 deletions
| diff --git a/rust/README.md b/rust/README.md index 8c742cb1..a6873345 100644 --- a/rust/README.md +++ b/rust/README.md @@ -63,6 +63,36 @@ on a bare server, as root:      cd /srv/fatcat/fatcat/rust      cargo run +### Dumps and Backups + +There are a few different databaase dump formats folks might want: + +- raw native database backups, for disaster recovery (would include +  volatile/unsupported schema details, user API credentials, full history, +  in-process edits, comments, etc) +- a sanitized version of the above: roughly per-table dumps of the full state +  of the database. Could use per-table SQL expressions with sub-queries to pull +  in small tables ("partial transform") and export JSON for each table; would +  be extra work to maintain, so not pursuing for now. +- full history, full public schema exports, in a form that might be used to +  mirror or enitrely fork the project. Propose supplying the full "changelog" +  in API schema format, in a single file to capture all entity history, without +  "hydrating" any inter-entity references. Rely on separate dumps of +  non-entity, non-versioned tables (editors, abstracts, etc). Note that a +  variant of this could use the public interface, in particular to do +  incremental updates (though that wouldn't capture schema changes). +- transformed exports of the current state of the database (aka, without +  history). Useful for data analysis, search engines, etc. Propose supplying +  just the Release table in a fully "hydrated" state to start. Unclear if +  should be on a work or release basis; will go with release for now. Harder to +  do using public interface because of the need for transaction locking. + +Backing up the entire database using `pg_dump`, with parallelism 1 (use more on +larger machine with fast disks; try 4 or 8?), assuming the database name is +'fatcat', and the current user has access: + +    pg_dump -j1 -Fd -f test-dump fatcat +  ### Special Tricks  Regenerate API schemas (this will, as a side-effect, also run `cargo fmt` on | 
