diff options
| -rw-r--r-- | README.md | 22 | ||||
| -rw-r--r-- | obnam.md | 42 |
2 files changed, 32 insertions, 32 deletions
@@ -1,8 +1,8 @@ --- -title: Obnam – a backup system +title: Obnam — a backup system ... -# Obnam – a backup system +# Obnam — a backup system Obnam2 is a project to develop a backup system. @@ -22,44 +22,44 @@ The Rust dependencies are handled automatically by the Cargo tool on all platforms. The other dependencies are, not including ones needed merely for building Debian packages: -* [daemonize](http://software.clapper.org/daemonize/) – a tool +* [daemonize](http://software.clapper.org/daemonize/) — a tool for running a command as a daemon in the background; needed for testing, so that the Obnam server can be started and stopped by the Obnam test suite. * [SQLite](https://sqlite.org), specifically its development library - component – an SQL database engine that stores the whole + component — an SQL database engine that stores the whole database in a file and can be used as a library rather then run as a service. * [OpenSSL](https://www.openssl.org), specifically its development - library component known as `libssl-dev` – a library that + library component known as `libssl-dev` — a library that implments TLS, which Obnam uses for communication between its client and server parts. -* [moreutils](https://joeyh.name/code/moreutils/) – a collection +* [moreutils](https://joeyh.name/code/moreutils/) — a collection of handy utilities, of which the Obnam test suite uses the `chronic` tool to hide output of successful commands. -* [pkg-config](http://pkg-config.freedesktop.org) – a tool for +* [pkg-config](http://pkg-config.freedesktop.org) — a tool for managing compile and link time flags; needed so that the OpenSSL library can be linked into the Obnam binaries. * [Python 3](https://www.python.org/), [Requests](http://python-requests.org), - [PYYAML](https://github.com/yaml/pyyaml) – programming + [PYYAML](https://github.com/yaml/pyyaml) — programming language and libraries for it, used by the Obnam test suite. -* [Subplot](https://subplot.liw.fi) – a tool for documenting +* [Subplot](https://subplot.liw.fi) — a tool for documenting acceptance criteria and verifying that they are met. -* [TeX Live](http://www.tug.org/texlive/) – a typesetting system +* [TeX Live](http://www.tug.org/texlive/) — a typesetting system for generating PDF versions of documentation. The LaTeX implementation and fonts are needed, not the full suite. None of Tex Live is needed, if PDFs aren't needed, but `./check` does not currently have a way to be told not to generate PDFs. -* [Summain](https://summain.liw.fi) – a tool for generating +* [Summain](https://summain.liw.fi) — a tool for generating manifests of files. Used by the Obnam test suite to verify restored data matches the original data. @@ -574,45 +574,45 @@ use [lstat(2)][] instead. The metadata is stored in an [inode][]. Both variants return a C `struct stat`. On Linux, it has the following fields: -* `st_dev` – id of the block device containing file system where +* `st_dev` — id of the block device containing file system where the file is; this encodes the major and minor device numbers - this field can't be restored as such, it is forced by the operating system for the file system to which files are restored - Obnam stores it so that hard links can be restored, see below -* `st_ino` – the inode number for the file +* `st_ino` — the inode number for the file - this field can't be restored as such, it is forced by the file system whan the restored file is created - Obnam stores it so that hard links can be restored, see below -* `st_nlink` – number of hard links referring to the inode +* `st_nlink` — number of hard links referring to the inode - this field can't be restored as such, it is maintained by the operating system when hard links are created - Obnam stores it so that hard links can be restored, see below -* `st_mode` – file type and permissions +* `st_mode` — file type and permissions - stored and restored -* `st_uid` – the numeric id of the user account owning the file +* `st_uid` — the numeric id of the user account owning the file - stored - restored if restore is running as root, otherwise not restored -* `st_gid` – the numeric id of the group owning the file +* `st_gid` — the numeric id of the group owning the file - stored - restored if restore is running as root, otherwise not restored -* `st_rdev` – the device this inode represents +* `st_rdev` — the device this inode represents - not stored? -* `st_size` – size or length of the file in bytes +* `st_size` — size or length of the file in bytes - stored - restored implicitly be re-creating the origtinal contents -* `st_blksize` – preferred block size for efficient I/O +* `st_blksize` — preferred block size for efficient I/O - not stored? -* `st_blocks` – how many blocks of 512 bytes are actually +* `st_blocks` — how many blocks of 512 bytes are actually allocated to store this file's contents - see below for discussion about sparse files - not stored by Obnam -* `st_atime` – timestamp of latest access +* `st_atime` — timestamp of latest access - stored and restored - On Linux, split into two integer fields -* `st_mtime` – timestamp of latest modification +* `st_mtime` — timestamp of latest modification - stored and restored - On Linux, split into two integer fields -* `st_ctime` – timestamp of latest inode change +* `st_ctime` — timestamp of latest inode change - On Linux, split into two integer fields - stored - not restored @@ -788,18 +788,18 @@ Chunks consist of arbitrary binary data, a small amount of metadata, and an identifier chosen by the server. The chunk metadata is a JSON object, consisting of the following fields: -* `sha256` – the SHA256 checksum of the chunk contents as +* `sha256` — the SHA256 checksum of the chunk contents as determined by the client - this MUST be set for every chunk, including generation chunks - the server allows for searching based on this field - note that the server doesn't verify this in any way, to pave way for future client-side encryption of the chunk data -* `generation` – set to `true` if the chunk represents a +* `generation` — set to `true` if the chunk represents a generation - may also be set to `false` or `null` or be missing entirely - the server allows for listing chunks where this field is set to `true` -* `ended` – the timestamp of when the backup generation ended +* `ended` — the timestamp of when the backup generation ended - note that the server doesn't process this in any way, the contents is entirely up to the client - may be set to the empty string, `null`, or be missing entirely @@ -814,14 +814,14 @@ that can be put into HTTP headers. The server has the following API for managing chunks: -* `POST /chunks` – store a new chunk (and its metadata) on the +* `POST /chunks` — store a new chunk (and its metadata) on the server, return its randomly chosen identifier -* `GET /chunks/<ID>` – retrieve a chunk (and its metadata) from +* `GET /chunks/<ID>` — retrieve a chunk (and its metadata) from the server, given a chunk identifier -* `GET /chunks?sha256=xyzzy` – find chunks on the server whose +* `GET /chunks?sha256=xyzzy` — find chunks on the server whose metadata indicates their contents has a given SHA256 checksum -* `GET /chunks?generation=true` – find generation chunks -* `GET /chunks?data=True` – find chunks with file data +* `GET /chunks?generation=true` — find generation chunks +* `GET /chunks?data=True` — find chunks with file data - this is meant for testing only - it excludes generation chunks, and chunks used to store the generation's SQLite file |