Markdown: remove trailing-whitespace
Signed-off-by: Ralf Zerres <ralf.zerres@networkx.de>
This commit is contained in:
16
README.md
16
README.md
@@ -17,7 +17,7 @@ and combines it with managemnet functionality of `snapper`.
|
||||
|
||||
`dsnap-sync` creates backups as btrfs-snapshots on a selectable target device.
|
||||
Plug in and mount any btrfs-formatted device to your system. Supported targets
|
||||
may be either local attached USB drives, automountable RAID devices or LTFS
|
||||
may be either local attached USB drives, automountable RAID devices or LTFS
|
||||
aware tapes. All supported targets can be located on a remote host.
|
||||
If possible the backup process will send incremental snapshots to the target
|
||||
drive. If the snapshot will be stored on a remote host, the transport will be
|
||||
@@ -32,11 +32,11 @@ will offer details as a reference point.
|
||||
## Backup process
|
||||
|
||||
The default `dsnap-sync` backup process will iterate through all defined `snapper`
|
||||
configurations that are found on your source system.
|
||||
configurations that are found on your source system.
|
||||
|
||||
If you prefer to have single processes for each configuration or configuration
|
||||
groups, you are free to define isolated systemd-units. They will be triggerd
|
||||
interactively or via timer units. `dsnap-sync` will cycle through each
|
||||
groups, you are free to define isolated systemd-units. They will be triggerd
|
||||
interactively or via timer units. `dsnap-sync` will cycle through each
|
||||
referenced `snapper` configuration (option `-c` or `--config`).
|
||||
|
||||
For each selected `snapper` configuration `dsnap-sync`
|
||||
@@ -202,7 +202,7 @@ Please use your host software package manager.
|
||||
-s, --subvolid <subvlid> Specify the subvolume id of the mounted BTRFS subvolume to back up to. Defaults to 5.
|
||||
--use-btrfs-quota use btrfs-quota to calculate snapshot size
|
||||
-u, --uuid <UUID> Specify the UUID of the mounted BTRFS subvolume to back up to. Otherwise will prompt
|
||||
If multiple mount points are found with the same UUID, will prompt for user selection
|
||||
If multiple mount points are found with the same UUID, will prompt for user selection
|
||||
-t, --target <target> Specify the mountpoint of the backup device
|
||||
--volumename Specify the name of the tape volume
|
||||
-v, --verbose Be verbose on what's going on (min: --verbose=1, max: --verbose=3)
|
||||
@@ -244,7 +244,7 @@ backup types are differenciated:
|
||||
It is useful, if a selected `snapper` configuration from the source
|
||||
host will be synced to a target external disk (disk-2-disk-2-disk).
|
||||
The clone configuration will be managable via `snapper` as expected.
|
||||
Please be aware, that the target device must be a btrfs filesystem
|
||||
Please be aware, that the target device must be a btrfs filesystem
|
||||
that can save the snapshots.
|
||||
|
||||
* btrfs-archive
|
||||
@@ -259,7 +259,7 @@ backup types are differenciated:
|
||||
* create a config specific subdirectory (`archive-<config-name>`)
|
||||
* create a snapshot-id subdirectory (`<snapper-id>`)
|
||||
* create the btrfs stream file inside the subdirectory
|
||||
(`<snapper-id>_[full | incremental].btrfs`)
|
||||
(`<snapper-id>_[full | incremental].btrfs`)
|
||||
* the proccess metadata are saved to a file called `info.xml`
|
||||
|
||||
If you enabled the `ltfs` package, support for backups to tape is possible.
|
||||
@@ -306,7 +306,7 @@ An open-source implementation can be found at
|
||||
|
||||
## Contributing
|
||||
|
||||
Help is very welcome! Feel free to fork and issue a pull request to add
|
||||
Help is very welcome! Feel free to fork and issue a pull request to add
|
||||
features or tackle open issues. If you are requesting new features, please
|
||||
have a look at the TODO list. It might be already on the agenda.
|
||||
|
||||
|
||||
@@ -202,7 +202,7 @@ Software Paket Manager.
|
||||
-s, --subvolid <subvlid> Specify the subvolume id of the mounted BTRFS subvolume to back up to. Defaults to 5.
|
||||
--use-btrfs-quota use btrfs-quota to calculate snapshot size
|
||||
-u, --uuid <UUID> Specify the UUID of the mounted BTRFS subvolume to back up to. Otherwise will prompt
|
||||
If multiple mount points are found with the same UUID, will prompt for user selection
|
||||
If multiple mount points are found with the same UUID, will prompt for user selection
|
||||
-t, --target <target> Specify the mountpoint of the backup device
|
||||
--volumename Specify the name of the tape volume
|
||||
-v, --verbose Be verbose on what's going on (min: --verbose=1, max: --verbose=3)
|
||||
@@ -264,13 +264,13 @@ sorgen. Folgende Sicherungstypen werden unterschieden:
|
||||
* ein Unterverzeichnis des Konfigurations-Namens (`archive-<config-name>`)
|
||||
* ein Unterverzeichnis der Snapshot-ID (`<snapper-id>`)
|
||||
* der aktuelle btrfs Stream wird im Unterverzeichnis abgelegt
|
||||
(`<snapper-id>_[full | incremental].btrfs`)
|
||||
(`<snapper-id>_[full | incremental].btrfs`)
|
||||
* die Metadaten des Prozesses werden in der Datei `info.xml` abgelegt
|
||||
|
||||
Steht `ltfs` zur Verfügung, ist ein Backup auf Bänder möglich.
|
||||
Hierbei wird ein Band durch ltfs vorbereitet und kann anschließend in
|
||||
das Dateisystem unter einem definierten Pfad eingebunden werden
|
||||
('mount-point'). Eine `dsnap-sync` Sicherung auf diesen Pfad erfolgt
|
||||
('mount-point'). Eine `dsnap-sync` Sicherung auf diesen Pfad erfolgt
|
||||
über den Sicherungstyp `btrfs-archive`.
|
||||
|
||||
## Automounter
|
||||
@@ -295,35 +295,35 @@ des Beispiel Dokuments enthält weitere Details.
|
||||
|
||||
## Tape-Administration / LTFS
|
||||
|
||||
Wenn sie `dsnap-sync` für die Archivierung von Snapshots auf Bänder
|
||||
Wenn sie `dsnap-sync` für die Archivierung von Snapshots auf Bänder
|
||||
verwenden, sollten den Einsatz in Kombination mit LTFS überdenken.
|
||||
(WIP - work in progress: Die erster erfolgreicher Versuch wurde mit
|
||||
LTO7-Bändern in einem Quantum SuperLoader3 getestet).
|
||||
|
||||
Das Installations-Paket beinhaltet ein Hilfs-Skript `tape-admin`, das
|
||||
alle Basisaufgaben für die Administration von Bändern als Funktionen
|
||||
bereitstellt. Hardware, die einen mechanischen Bandwechsel ermöglicht
|
||||
bereitstellt. Hardware, die einen mechanischen Bandwechsel ermöglicht
|
||||
(z.B Quantum SuperLoader3), kann das Hilfs-Skript über das Paket `mtx`
|
||||
steuern. Dies beinhaltet das Auslesen von Barcodes als auch das Laden
|
||||
und Entladen von Bändern in wählbare Quell- und Ziel-Schächte (Slots).
|
||||
|
||||
(WIP: Die Zuordnung von Band-Namen zu Pools und Slots neben deren
|
||||
Media-Zugriffsrichtlienen wird in einer JSON-Datei beschrieben.
|
||||
Diese muss derzeit noch manuell gepflegt werden:
|
||||
Diese muss derzeit noch manuell gepflegt werden:
|
||||
`/etc/dsnap-sync/MediaPools.json`).
|
||||
|
||||
Werden Barcode-Labels selbst erstellt, prüfen Sie bitte Hinweise auf das
|
||||
zu verwendende Format. Üblicherweise unterstützen die Barcode-Leser
|
||||
zu verwendende Format. Üblicherweise unterstützen die Barcode-Leser
|
||||
"Code 39" Etiketten.
|
||||
|
||||
`LTFS` ist ein Ansatz, der Lese- und Schreib-Operationen auf Bänder in
|
||||
der für Festplatten üblichen Funktionsweise implementiert. Ab Geräten
|
||||
`LTFS` ist ein Ansatz, der Lese- und Schreib-Operationen auf Bänder in
|
||||
der für Festplatten üblichen Funktionsweise implementiert. Ab Geräten
|
||||
der LTO5 Generation sind Sie in der Lage, Bänder für die LTFS-Nutzung
|
||||
vorzubareiten (formatieren, bzw. partitionieren).
|
||||
Anschließend können erfolgreich formatierte Bänder in das Dateisystem
|
||||
eingehängt werden (FUSE). Das Beschreiben und Auslesen der Daten erfolgt
|
||||
dann mit den gewohnten Betriebssystem Tools. Eine Open-Source Implementierung
|
||||
finden Sie z.B. unter
|
||||
finden Sie z.B. unter
|
||||
[LinearTapeFileSystem](https://github.com/LinearTapeFileSystem/ltfs).
|
||||
|
||||
## Mitarbeit
|
||||
@@ -335,15 +335,15 @@ Vielleicht findet Ihr dort auch Anregungen.
|
||||
|
||||
## Ähnliche Projekte
|
||||
|
||||
`dsnap-sync` basiert auf dem ursprünglichen Code von Wes Barnetts. Als
|
||||
open-source war meine Intention, die Erweiterungen in das Projekt
|
||||
`dsnap-sync` basiert auf dem ursprünglichen Code von Wes Barnetts. Als
|
||||
open-source war meine Intention, die Erweiterungen in das Projekt
|
||||
zurückfliessen zu lassen. Neben der Tatsache, dass diese Version bashisms
|
||||
eleminiert hat, sieht Wes sich leider zeitlich ausser Stande, den neuen
|
||||
Code in angemessener Art und Weise zu prüfen um ihn anschließende in
|
||||
eleminiert hat, sieht Wes sich leider zeitlich ausser Stande, den neuen
|
||||
Code in angemessener Art und Weise zu prüfen um ihn anschließende in
|
||||
`snap-sync` einzubinden. Jeder ist willkommen dies zu tun.
|
||||
|
||||
Bis dahin habe ich mich entschlossen, die Ergebnisse als Fork unter dem
|
||||
Namen `dsnap-sync` zu veröffentlichen. Die Namensämderung soll mögliche
|
||||
Bis dahin habe ich mich entschlossen, die Ergebnisse als Fork unter dem
|
||||
Namen `dsnap-sync` zu veröffentlichen. Die Namensämderung soll mögliche
|
||||
Verwechslungen vermeinden.
|
||||
|
||||
## Lizenz
|
||||
|
||||
Reference in New Issue
Block a user