One-stop ZFS backup & replication solution
Go to file
2017-11-18 16:28:06 +01:00
cmd fixup: remove unused StdoutOutlet function 2017-11-17 00:36:48 +01:00
docs build: include docs in release artifacts + use sphinxcontrib-versioning 2017-11-18 16:28:06 +01:00
logger logging: first outlet receives logger error message 2017-11-17 00:25:38 +01:00
rpc fix unreachable code & missing stringer-generated code 2017-09-30 16:31:55 +02:00
sshbytestream config: connect: ssh_command parameter did not work 2017-10-05 20:11:04 +02:00
util cmd: logging using logrus 2017-09-22 17:01:54 +02:00
zfs bookmark every snapshot 2017-11-13 10:59:46 +01:00
.gitignore Rudimentary Makefile specifying requirements for a release 2017-09-30 16:40:39 +02:00
.gitmodules docs: move hugo docs to old directory 2017-11-11 23:25:12 +01:00
clone_and_build.sh build: include docs in release artifacts + use sphinxcontrib-versioning 2017-11-18 16:28:06 +01:00
Gopkg.lock logging: stdout outlet: include time in output if tty or forced through config 2017-11-15 11:04:34 +01:00
Gopkg.toml implement logfmt formatter 2017-09-24 02:09:50 +02:00
LICENSE license: change attribution 2017-05-03 18:28:04 +02:00
main.go Switch to using https://github.com/spf13/cobra for CLI. 2017-07-06 13:36:55 +02:00
Makefile build: include docs in release artifacts + use sphinxcontrib-versioning 2017-11-18 16:28:06 +01:00
README.md README: remove obsolete dirs in developer docs 2017-11-16 21:49:49 +01:00

zrepl

zrepl is a ZFS filesystem backup & replication solution written in Go.

User Documentation

User Documentation can be found at zrepl.github.io.

Bug Reports

  1. If the issue is reproducible, enable debug logging, reproduce and capture the log.
  2. Open an issue on GitHub, with logs pasted as GitHub gists / inline.

Feature Requests

  1. Does you feature request require default values / some kind of configuration? If so, think of an expressive configuration example.
  2. Think of at least one use case that generalizes from your concrete application.
  3. Open an issue on GitHub with example conf & use case attached.

The above does not apply if you already implemented everything. Check out the Coding Workflow section below for details.

Developer Documentation

Overall Architecture

The application architecture is documented as part of the user docs in the Implementation section (docs/content/impl). Make sure to develop an understanding how zrepl is typically used by studying the user docs first.

Project Structure

├── cmd
│   ├── sampleconf          # example configuration
├── docs                    # sphinx-based documentation
│   ├── **/*.rst            # documentation in reStructuredText
│   ├── conf.py             # sphinx configuration
│   ├── publish.sh          # shell script for automated rendering & deploy to zrepl.github.io repo
│   ├── public_git          # checkout of zrepl.github.io used by above shell script
├── logger                  # logger package used by zrepl
├── rpc                     # rpc protocol implementation
├── sshbytestream           # io.ReadWriteCloser over SSH
├── util
└── zfs                     # ZFS wrappers, filesystemm diffing

Coding Workflow

  • Open an issue when starting to hack on a new feature
  • Commits should reference the issue they are related to
  • Docs improvements not documenting new features do not require an issue.

Breaking Changes

Backward-incompatible changes must be documented in the git commit message and are listed in docs/changelog.rst.

  • Config-breaking changes must contain a line BREAK CONFIG in the commit message
  • Other breaking changes must contain a line BREAK in the commit message

Glossary & Naming Inconsistencies

In ZFS, dataset refers to the objects filesystem, ZVOL and snapshot.
However, we need a word for filesystem & ZVOL but not a snapshot, bookmark, etc.

Toward the user, the following terminology is used:

  • filesystem: a ZFS filesystem or a ZVOL
  • filesystem version: a ZFS snapshot or a bookmark

Sadly, the zrepl implementation is inconsistent in its use of these words: variables and types are often named dataset when they in fact refer to a filesystem.

There will not be a big refactoring (an attempt was made, but it's destroying too much history without much gain).

However, new contributions & patches should fix naming without further notice in the commit message.

Building docs

cd docs
pip install sphinx sphinx-rtd-theme
make clean html
xdg-open _build/html/index.html