rzerres/dsnap-sync
1
0
Fork 0
Code Issues Pull Requests Releases 1 Activity

Merge branch 'wip-d2d'

Browse Source 
Signed-off-by: Ralf Zerres <ralf.zerres@networkx.de>
This commit is contained in:
Ralf Zerres
2018-09-21 19:35:03 +02:00
parent f65987e418 d6fffcffe6
commit 629786d9ec
12 changed files with 2616 additions and 1516 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
.gitignore vendored
View File

@@ -1,8 +0,0 @@
*~
*.bak
AUR/*
PKGBUILD
pkg/*
*.tar*
*.gz
*.xz

386
README.md
View File

@@ -1,30 +1,91 @@
<!-- dsnap-sync README.md -->
<!-- version: 0.5.2 -->
<!-- version: 0.5.9 -->
# dsnap-sync
<p align="center">
<span>English</span> |
<!-- a href="lang/spanish#dsnap-sync">Spanish</a> | -->
<a href="lang/german#dsnap-sync">Deutsch</a>
</p>
## About
`dsnap-sync` is designed to backup btrfs formated filesystems.
It takes advantage of the specific snapshots functionality btrfs offers
and combines it with managemnet functionality of snapper.
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 devices
may be either local USB drives, but can be as well remote accessible RAID drives.
If possible the backup process will send incremental snapshots to the target drive.
If the snapshot will be stored on a remote host, it is secured with ssh.
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
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
secured with ssh.
The tool is implemented as a posix shell script, to keep the footprint small (dash).
`dsnap-sync` will support interactive and time scheduled backup runs.
The tool is implemented as a posix shell script (dash), to keep the footprint
small. `dsnap-sync` will support interactive and time scheduled backup processes.
Scheduling should be implemented as a pair of systemd service and timer-units.
The [example section](usr/share/doc/dsnap-sync/Examples.md#systemd)
will offer details as a reference point.
## Backup process
For a backup run, and per default `dsnap-sync` will iterate through all defined snapper
configurations found on your source system. If you prefer to just run on a specific
configuration per call, you are free to select it using the 'config' option `-c`.
The default `dsnap-sync` backup process will iterate through all defined `snapper`
configurations that are found on your source system.
For each selected snapper configuration `dsnap-sync`
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
referenced `snapper` configuration (option `-c` or `--config`).
For each selected `snapper` configuration `dsnap-sync`
* will present/select target device informations
* will prepare snapper structures
* will perform the actual backup
(handle backupdir, handle snapper structures, handle btrfs send / btrfs recieve)
* will finalize the actual backup
(update snapper metadata for each source and target snapshot)
* will perform cleanup tasks
Usualy other tools will document this proccess as a disk to disk (d2d) backup.
If possible `dsnap-sync` will levarage `btrfs send` capabilities to only
send deltas. It will compare snapshot data of the source snapshot with available
snapshot data on the target device. If a common snapshot id exists on source and
target, `dsnap-sync` will prepare the `btrfs send / btrfs receive` pipe to use
them respectively. This functionality dasticly reduces the time a sync process
will need to complete compared to a full backup process.
### Interactive backups
An interactive process will gide you to select a backup target.
You can pre-select the target via [command line options](./README.md#Options).
To uniquely define / select a target devices you either need to choose
* a pair of a btrfs UUID and SUBVOLID
* a TARGET name (read 'mount point')
* a MediaPool / Tape VolumeName
This will asure, that `dsnap-sync` can distinguish backup processes that
have a commen source device, but save data to different target devices. As
an example it might be advisable, to save the project subvolume redundantly
on to independent targets (disk and tape).
Before `dsnap-sync` will perform the backup, it will present the backupdir,
and spit out the source and target locations. You have to confirm or adapt
the given values. You may use commandline options to supress interaction
(e.g --noconfirm, --batch).
### Scheduled backups
A scheduled process should be defined as a systemd unit. Inside the unit
definition the execution parameter will take the `dsnap-sync` call, appending
all needed parameters as config options. In combination with a corresponding
systemd timer unit, you are able to fine tune your backup needs.
The [example section](usr/share/doc/dsnap-sync/Examples.md#systemd)
will offer details as a reference point.
* will create an appropriate local snapshot and update the metadata
* will transfer the snapshot using btrfs-send to the target device
@@ -42,206 +103,216 @@ An interactive run will request you to select a mounted btrfs device.
You can pre-select the target drive via [command line options](https://github.com/rzerres/dsnap-sync#options).
Either use a UUID, a SUBVOLID or a TARGET name (read 'mount point').
### Scheduled backups
A scheduled run will take all needed parameters from config options.
`dsnap-sync` does support systemd.timer units. Please refer to related paragraph [documenting systemd](https://github.com/rzerres/dsnap-sync#systemd).
## Requirements
g
beside the shell itself, `dsnap-sync`relies on external tools to achieve its goal.
At run-time their availability is checked. Following tools are are used:
### dsnap-sync
Beside the posix shell itself (e.g. `dash`), `dsnap-sync`relies on external
tools to achieve its goal. At run-time their availability is checked.
Following tools are used:
- awk
- btrfs
- findmnt
- sed
- snapper
- tee
- wc
- ssh / scp
optionaly tools
As an option, you can enrich interactive responses using
- notify-send
- pv
### tape-admin
Beside the posix shell itself (e.g. `dash`), `dsnap-sync`relies on external
tools to achieve its goal. At run-time their availability is checked.
Following tools are used:
- jq
- ltfs
- mkltfs
- mtx
- perl
- sed
## Installation
### Building from source
`dsnap-sync` is a shell script. Thus no compilation is required.
To simplify correct target locations, this project uses a Makefile.
# make install
If your system uses a non-default location for the snapper
configuration file, specify it on the command line with
`SNAPPER_CONFIG`. For example, for Arch Linux use:
configuration defaults, specify the location with an environment variable
(`SNAPPER_CONFIG`).
Arch Linux/Fedora/Gentoo:
# make SNAPPER_CONFIG=/etc/conf.d/snapper install
The local snapper configuration will be extended to make use
Debian/Ubuntu:
# make SNAPPER_CONFIG=/etc/default/snapper install
The local `snapper` configuration will be extended to make use
of a new template 'dsnap-sync'.
The package is also available in the
[AUR](https://aur.archlinux.org/packages/dsnap-sync/).
### Using distribution packages
If available, you can install `dsnap-sync` as a precompiled package.
Please use your host software package manager.
<!--
* For ARCH-Linux
[AUR package](https://aur.archlinux.org/packages/dsnap-sync)
-->
<!-- For Debian
[deb package](https://packages.debian.org/dsnap-sync). -->
<!-- For Ubuntu
[deb package](https://packages.ubuntu.org/dsnap-sync). -->
## Options
Usage: dsnap-sync [options]
Options:
-d, --description <desc> Change the snapper description. Default: "latest incremental backup"
-c, --config <config> Specify the snapper configuration to use. Otherwise will perform for each snapper
configuration. Can list multiple configurations within quotes, space-separated
(e.g. -c "root home").
-n, --noconfirm Do not ask for confirmation for each configuration. Will still prompt for backup
directory name on first backup
-u, --uuid <UUID> Specify the UUID of the mounted BTRFS subvolume to back up to. Otherwise will prompt.
--UUID <UUID> If multiple mount points are found with the same UUID, will prompt user.
-s, --subvolid <subvlid> Specify the subvolume id of the mounted BTRFS subvolume to back up to. Defaults to 5.
--SUBVOLID
-t, --target <target> Specify the mountpoint of the BTRFS subvolume to back up to.
--TARGET <target>
--remote <address> Send the snapshot backup to a remote machine. The snapshot will be sent via ssh. You
should specify the remote machine's hostname or ip address. The 'root' user must be
permitted to login on the remote machine.
--dry-run perform a trial run with no changes made.
-v, --verbose Be more verbose on what's going on.
Options:
-a, --automount <path> start automount for given path to get a valid target mountpoint.
-b, --backupdir <prefix> backupdir is a relative path that will be appended to target backup-root
--backuptype <type> Specify backup type <archive | child | parent>
--batch no user interaction
-d, --description <desc> Change the snapper description. Default: "latest incremental backup"
--label-finished <desc> snapper description tagging successful jobs. Default: "dsnap-sync backup"
--label-running <desc> snapper description tagging active jobs. Default: "dsnap-sync in progress"
--label-synced <desc> snapper description tagging last synced jobs.
Default: "dsnap-sync last incremental"
--color Enable colored output messages
-c, --config <config> Specify the snapper configuration to use. Otherwise will perform for each snapper
configuration. You can select multiple configurations
(e.g. -c "root" -c "home"; --config root --config home)
--config-postfix <name> Specify a postfix that will be appended to the destination snapper config name.
--dry-run perform a trial run (no changes are written).
--mediapool Specify the name of the tape MediaPool
-n, --noconfirm Do not ask for confirmation for each configuration. Will still prompt for backup
--nonotify Disable graphical notification (via dbus)
--nopv Disable graphical progress output (disable pv)
--noionice Disable setting of I/O class and priority options on target
-r, --remote <address> Send the snapshot backup to a remote machine. The snapshot will be sent via ssh
You should specify the remote machine's hostname or ip address. The 'root' user
must be permitted to login on the remote machine
-p, --port <port> The remote port
-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
-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)
--version show program version
## First run
If you have never synced to the paticular target device (first run), `dsnap-sync`
will take care to create the necessary target file-structure to store the snapshot.
As an option you can prepend a backup-path.
will take care to create the necessary target filesystem-structure. Following
backup types are differenciated:
Before the sync job is started, source and target locations will be presented.
You have to confirm any further operation, or use defaults (option: noconfirm).
* btrfs-snapshots
## Example command line usage
This is the default backup type. `dsnap-sync` will use this type to sync
a btrfs-snapshot of an existing `snapper` configuration from a source
device to a target device. On the target device the needed `snapper`
structure will be build up as needed. Aside the new target filesystem
path, `dsnap-sync` will create a new target `snapper` configuration. It
will incorporate the template (`/etc/snapper/config-templates/dsnap-sync`).
To garantee unique configuration names, `dsnap-sync` take the source
configuration name and postfix it with targets hostname. You can adopt
this behaviour with a config option (`--config-postfix`).
### dsnap-sync to local target
The default `config-template` of dsnap-sync will inherit following
`snapper` parameters:
#### Default: no selections, run for all snapper configs
* mark new snapshots as type 'single'
* mark new snaphosts with cleanup-algorithm 'timeline'
* apply config option 'CONFIG_TYPE=child'
* apply config option 'TIMELINE_CREATE=no'
* apply config option 'TIMELINE_CLEANUP=yes'
# dsnap-sync
Please adapt the defaults, if your milage varies.
#### Default: Select two configs, the backupdir and verbose output
* btrfs-clone
# dsnap-sync --verbose --config root --config data2 --backupdir=toshiba_r700
To duplicate an existing `snapper` configuration within a source host,
you should use this backup type.
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
that can save the snapshots.
#### Dry-run: Select config, select Target, as batchjob (--noconfirm)
* btrfs-archive
# dsnap-sync -c root -s 265 --noconfirm --dry-run
If the target device is not a btrfs filesystem (e.g. ext4,
xfs, ltofs tapes), you need to use this backup type.
`dsnap-sync` will take the data of the source snapshot-ID and copy the
data as a stream file inside ther target-subdirectory. `dsnap-sync` will
mimic a `snapper` structure inside the 'target-subdirectory':
### dsnap-sync to remote host
* 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`)
* the proccess metadata are saved to a file called `info.xml`
`dsnap-sync` will rely on ssh access to the target host. For batch usage make sure, that your
public key is accepted for remote login as user 'root'. You may have to adapt /root/.ssh/authorized_keys
on the target host.
If you enabled the `ltfs` package, support for backups to tape is possible.
ltfs will prepare a tape, than can be mounted afterwards to a selectable
mount-point. A `dsnap-sync` backup to this path will be handeld as type
`btrfs-archive`.
On your target host, you should also verify the availability of a dsnap-sync config-template for snapper.
A template `dsnap-sync` is included in the package for your convenience.
## Automounter
#### Dryrun: Select remote host <ip/fqdn>, interactive, run for all configs
`dsnap-sync` offer all mounted btrfs filesystems as valid process targets.
Since storage space on disks are very price efficient this days, environments
often use removable, external disks as additional backup targets. If the
external disks aren't mounted at boot time they can't be addressed by the
selection function. It's even advisable to not mount them all the time
(e.g prevent risks for malware encryption attacks).
dsnap-sync --dry-run --remote 172.16.0.3
Selecting a mounted BTRFS device for backups on 172.16.0.3.
0) / (uuid=5af3413e-59ea-4862-8cff-304afe25420f,subvolid=257,subvol=/root)
1) /.snapshots (uuid=5af3413e-59ea-4862-8cff-304afe25420f,subvolid=258,subvol=/@snapshots-root)
2) /data2 (uuid=62a45211-9197-4a5f-aeaf-0ab803a42c32,subvolid=261,subvol=/data2)
3) /home (uuid=62a45211-9197-4a5f-aeaf-0ab803a42c32,subvolid=258,subvol=/home)
4) /data2/.snapshots (uuid=62a45211-9197-4a5f-aeaf-0ab803a42c32,subvolid=262,subvol=/@snapshots-data2)
5) /home/.snapshots (uuid=62a45211-9197-4a5f-aeaf-0ab803a42c32,subvolid=259,subvol=/@snapshots-home)
6) /var/lib/machines (uuid=2ba04452-74aa-44df-b1c7-74e0a70c6543,subvolid=260,subvol=/machines)
7) /var/lib/libvirt (uuid=2ba04452-74aa-44df-b1c7-74e0a70c6543,subvolid=261,subvol=/libvirt)
8) /data (uuid=2ba04452-74aa-44df-b1c7-74e0a70c6543,subvolid=257,subvol=/data)
9) /var/lib/machines/.snapshots (uuid=2ba04452-74aa-44df-b1c7-74e0a70c6543,subvolid=2121,subvol=/@snapshots-machines)
10) /data/.snapshots (uuid=2ba04452-74aa-44df-b1c7-74e0a70c6543,subvolid=258,subvol=/@snapshots-data)
11) /var/lib/dsnap-sync (uuid=753eba7a-41ce-49e0-b2e3-24ee07811efd,subvolid=420,subvol=/dsnap-sync)
x) Exit
Enter a number: 11
To link in external disks dynamically, but also asure a persistent naming
syntax, we can use them as auto-mountable targets. To wakeup the automount
proccess before parsing available target disks, append the target mount-point
as a config option to `dsnap-sync` (e.g: `--automount /var/backups/archive-disk1`).
The [example section](usr/share/doc/dsnap-sync/Examples.md#Automounter)
will offer details as a reference point.
## Tape-Administration / LTFS
### Dry-run with given Target for snapper config 'home', no confirmations
If you use `dsnap-sync` to archive snapshots on a tape, consider to use it
in combination with LTFS. (Work in Progress: Initial support is tested
with LTO7-Tapes in a Quantum SuperLoader3).
#### Sync: Select config 'data2', remote host <ip/fqdn>, target '/data', as batchjob (--noconfirm)
The installation package will include a wrapper script `tape-admin`, which
implements all common tasks that are needed for tape administration.
If you are able to make use of a tape-changer (e.g Quantum SuperLoader3) the
wrapper will take advantage of the `mtx` package to handle barcodes and slot
management. If you create your own barcodes, please consult the documentation
of your Loader-Device. Most likely they do support "Code 39"-Type labels.
# dsnap-sync --config data2 --remote 172.16.0.3 --target /data --noconfirm
## systemd
### service
[Unit]
Description=Run dsnap-sync backup
[Install]
WantedBy=multi-user.target
[Service]
Type=simple
ExecStart=/usr/bin/dsnap-sync --UUID 7360922b-c916-4d9f-a670-67fe0b91143c --subvolid 5 --noconfirm
### timer
[Unit]
Description=Run dsnap-sync weekly
[Timer]
OnCalendar=weekly
AccuracySec=12h
Persistent=true
[Install]
WantedBy=timers.target
## snapper template
###
# template for dsnap-sync handling
###
# subvolume to snapshot
SUBVOLUME="/var/lib/dsnap-sync"
# filesystem type
FSTYPE="btrfs"
# users and groups allowed to work with config
ALLOW_USERS=""
ALLOW_GROUPS="adm"
# sync users and groups from ALLOW_USERS and ALLOW_GROUPS to .snapshots
# directory
SYNC_ACL="yes"
# start comparing pre- and post-snapshot in background after creating
# post-snapshot
BACKGROUND_COMPARISON="yes"
# run daily number cleanup
NUMBER_CLEANUP="no"
# limit for number cleanup
NUMBER_MIN_AGE="1800"
NUMBER_LIMIT="10"
NUMBER_LIMIT_IMPORTANT="2"
# use systemd.timer for timeline
TIMELINE_CREATE="no"
# use systemd.timer for cleanup
TIMELINE_CLEANUP="no"
# dsnap-sync as timer unit
SNAP_SYNC_EXCLUDE="yes"
`LTFS` is an attempt to offer read and write-access functionality to serial
tapes in a way that's common with hard drives. From LTO5 onwards, your are
able to format/partition the tape with LTFS-Tools. After the successfull
preparation the LTFS-Tape can be mounted to a selectable mountpoint (via
FUSE). Read and write access can be managed using common OS tools.
An open-source implementation can be found at
[LinearTapeFileSystem](https://github.com/LinearTapeFileSystem/ltfs).
## Contributing
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.
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.
## Related projects
I did fork from Wes Barnetts original work. I was aiming merged it back.
I did fork from Wes Barnetts original work. I intend to merged it back.
Beside the fact that this version doesn't use any bashisms, Wes did let me know,
that he doesn't have the time to review the changes appropriately to make it a merge.
Anyone willing to do so is invided.
@@ -249,7 +320,6 @@ Anyone willing to do so is invided.
Until that date, i will offer this fork for the public. To overcome any name clashes
i renamed it to dsnap-sync.
## License
<!-- License source -->

18
TODO.md
View File

@@ -2,10 +2,17 @@
## open tasks ##
- dsnap-sync: supply saving streams to tape or other filesystemd
e.g like documented in btrfs wiki
# btrfs subvolume snapshot -r / /my/snapshot-YYYY-MM-DD && sync
# btrfs send /my/snapshot-YYYY-MM-DD | ssh user@host 'cat >/backup/home/snapshot-YYYY-MM-DD.btrfs'
# btrfs subvolume snapshot -r / /my/incremental-snapshot-YYYY-MM-DD && sync
# btrfs send -p /my/snapshot-YYYY-MM-DD /my/incremental-snapshot-YYYY-MM-DD | ssh user@host 'cat >/backup/home/incremental-snapshot-YYYY-MM-DD.btrfs'
- dsnap-sync: introduce snapper config handling for parent/child types
disk2disk -> parent to child on btrfs (default: snapshot)
disk2disk2disk -> child to child on btrfs (clone snapshot)
disk2disk2tape -> child to tape on non-btrfs (send btrfs-stream of snapshot if incremental, copy snapshot if first/full)
- dsnap-sync: parallel tasks per config
- dsnap-sync: introduce snapper function: important snapshots
Important snapshots have important=yes in the userdata
let snapper cleanup/timeline mechanisms respect this
## finished tasks ##
@@ -18,3 +25,8 @@
- dsnap-sync: port as posix compatible
- dsnap-sync: introduce selectable subvolid option
- dsnap-sync: use snapper to administer target synced snapshots
- dsnap-sync: introduce snapper function: important snapshots
Important snapshots have important=yes in the userdata
let snapper cleanup/timeline mechanisms respect this
- tape-admin: handle common tasks for tape-changer administration
- tape-admin: handle common tasks for ltfs tape administration

360
lang/german/README.md Normal file
View File

@@ -0,0 +1,360 @@
<!-- dsnap-sync README.md -->
<!-- version: 0.5.9 -->
# dsnap-sync
## Über
`dsnap-sync` ist konzipiert, um Backups für btrfs formatierte Dateisysteme
durchzuführen. Es bedient sich der von btrfs bereitgestellten Snapshot
Funktionalität und kombiniert diese mit den Management-Funktionen von
`snapper`.
`dsnap-sync` erstellt die Sicherungen als btrfs-Snapshots auf einem Ziel-Gerät.
Hierzu muss das Gerät zunächst formatiert und anschließend im Betriebssystem
bereitgestellt werden. Das unterstützte Ziel-Medium ist entweder
eine USB Festplatte, ein automatisch eingelinktes RAID System, oder ein LTFS
formatiertes Band. Alle unterstützten Ziel-Geräte können sich auch auf einem
einem entfernten Host befinden.
Wenn möglich wird der Sicherungs-Prozess nur die inkrementellen Veränderungen
im Snapshot auf das Ziel-Gerät übertragen. Bei Sicherungen auf einem entfernten
Host wird die Übertragung mittels ssh gesichert.
Mit Blick auf Portabilität und Ressourcen-Schonung wurde `dsnap-sync`als Posix
Shell Script implementiert (dash). Es unterstützt sowohl interaktive als auch
zeitgesteuerte Sicherungs-Prozesse. Zeitgesteuerte Sicherungen sollten als
systemd Einheiten (service- und timer-units) implementiert werden.
Für Details wird auf den [Beispiel-Abschnitt](../../usr/share/doc/dsnap-sync/Examples.md#systemd)
verweisen.
## Sicherungs-Prozess
Für einen Sicherungs-Prozess wird `dsnap-sync` in der Standardkonfiguration
alle definierten `snapper` Konfigurationen des Quell-Systems einbeziehen.
Wenn Sie es vorziehen, individuelle Sicherungs-Prozesse je `snapper` Konfiguration
oder Konfigurations-Gruppen einzurichten, sollten sie eigenständige systemd units
definieren. Diese können anschließend interaktiv oder über timer units
aufgerufen werden.
`dsnap-sync` wird alle refenzierten `snapper` Konfigurationen im Sicherungslauf
berücksichtigen (Option: `-c` oder `--config`).
Für jede ausgewählte `snapper` Konfiguration wird `dsnap-sync`
* die Ziel-Geräte Informationen anzeigen/auswählen
* die snapper Strukturen vorbereiten
* die eigentliche Sicherung ausführen
(Verarbeitung für backupdir, snapper Strukturen, btrfs send / btrfs recieve)
* abschließende Sicherungs-Arbeiten ausführen
(Aktualisierung der snapper Metadata für jeden Quell- und Ziel-Snapshot)
* abschließende Aufräumarbeiten durchführen
Üblicherweise beschreiben artverwandte Tools diesen Prozess als
Disk to Disk (d2d) Sicherung. Wenn möglich wird `dsnap-sync` die
`btrfs send / btrfs recieve` Funktionen nutzen, um nur Veränderungen des
Snapshots zur übertragen. Dabei vergleicht es Snapshot-Daten des Quell
Systems mit Snapshot-Daten des Ziel Systems. Existiert eine gemeinsame
Snapshot-ID auf beiden Systemen, wird `dsnap-sync` die
`btrfs send / btrfs receive` Pipe vorbereiten und die Daten transferieren.
Im Vergleich zu einer klassischen Voll-Sicherung verkürzt dies die
benötigte Übertragungszeit erheblich.
### Interaktive Sicherungen
Ein interkativer Sicherungsprozess wird Ihnen die Auswahl eines
Ziel-Gerätes anbieten. Sie können dieses Ziel-Gerät mit
[Kommando-Zeilen Parametern](./README.md#Optionen) vorauswählen.
Um eine eindeutige Zuordung eines Ziel-Gerätes sicherzustellen,
müssen sie entweder
* ein Paar aus btrfs UUID und SUBVOLID
* ein Target (hier: 'mount point')
* ein MediaPool / Band-Name
auswählen. Damit ist `dsnap-sync` in der Lage Sicherungsprozesse zu
unterscheiden, die als Quelle den gleichen Snapshot haben, jedoch
auf unterschiedliche Ziele gesichert werden sollen. Als Beispiel sei
angeführt, dass Projektdaten redundant auf voneinander unabhängige
Ziel-Medien (Festplatten, Bänder) gesichert werden müssen.
Bevor `dsnap-sync` das eigentliche Backup durchführt, wird es Ihnen
die Möglichkeit anbieten, einen Backup-Pfad (backudir) auszuwählen.
Darüber hinaus werden Quell und Ziel Informationen ausgewiesen.
Sie können die Aufforderung zur Bestätigung der Parameter über
Kommandozeilen-Parameter unterdrücken (z.B --noconfirm, --batch).
### Zeitgesteuerte Sicherungen
Eine zeitliche Steuerung von Sicherungs-Prozessen sollte über
systemd-units definiert werden. Innerhalb der systemd.service
Definition wird in der [Service] Sektion der ExecStart Parameter
als `dsnap-sync` Aufruf mit allen gewünschten Optionen eingestellt.
In Verbindung mit einer zugehörigen systemd.timer Definition sind
sie in der Lage, unterschiedliche Ausführungszeiten mit selektierten
Optionen umzusetzen. Für Details wird auf den
[Beispiel-Abschnitt](../../usr/share/doc/dsnap-sync/Examples.md#systemd)
verweisen.
## Anforderungen
### dsnap-sync
Neben der eigentlichen Posix Shell (e.g. `dash`), bedient sich
`dsnap-sync` externer Tools, um die gewünschte Funktionalität
bereitzustellen. Deren Verfügbarkeit wird zur Laufzeit überprüft.
Folgende Tools werden verwendet:
- awk
- btrfs
- findmnt
- sed
- snapper
- ssh / scp
Optional können interaktive Rückmeldungen mit foldenen Tools ergänzt
werden:
- notify-send
- pv
### tape-admin
Neben der eigentlichen Posix Shell (e.g. `dash`), bedient sich
`tape-admin` externer Tools, um die gewünschte Funktionalität
bereitzustellen. Deren Verfügbarkeit wird zur Laufzeit überprüft.
Folgende Tools werden verwendet:
- jq
- ltfs
- mkltfs
- mtx
- perl
- sed
## Installation
### Aus den Quellen
`dsnap-sync` ist ein Shell Script. Daher ist keine Kompilierung
erforderlich. Über ein Makefile wird die Installation an den
richtigen Ziel-Pfad gesteuert.
# make install
Sollte Ihr System einen unüblichen Speicherort für die snapper
Konfigurationen verwenden, kann der Pfad in einer Umgebungs-Variable
für die Installation einbezogen werden (`SNAPPER_CONFIG`).
Arch Linux/Fedora/Gentoo:
# make SNAPPER_CONFIG=/etc/conf.d/snapper install
Debian/Ubuntu:
# make SNAPPER_CONFIG=/etc/default/snapper install
Die lokalen `snapper` Konfiguration werden um ein neues Template
'dsnap-sync' ergänzt.
### Verwendung eines Distributions-Pakets
Wenn verfügbar können sie `dsnap-sync` als vorkonfiguriertes Paket
installieren. Bitte verwenden sie hierzu den Betriebssystem eigenen
Software Paket Manager.
<!--
* For ARCH-Linux
[AUR package](https://aur.archlinux.org/packages/dsnap-sync)
-->
<!-- For Debian
[deb package](https://packages.debian.org/dsnap-sync). -->
<!-- For Ubuntu
[deb package](https://packages.ubuntu.org/dsnap-sync). -->
## Optionen
Usage: dsnap-sync [options]
Options:
-a, --automount <path> start automount for given path to get a valid target mountpoint.
-b, --backupdir <prefix> backupdir is a relative path that will be appended to target backup-root
--backuptype <type> Specify backup type <archive | child | parent>
--batch no user interaction
-d, --description <desc> Change the snapper description. Default: "latest incremental backup"
--label-finished <desc> snapper description tagging successful jobs. Default: "dsnap-sync backup"
--label-running <desc> snapper description tagging active jobs. Default: "dsnap-sync in progress"
--label-synced <desc> snapper description tagging last synced jobs.
Default: "dsnap-sync last incremental"
--color Enable colored output messages
-c, --config <config> Specify the snapper configuration to use. Otherwise will perform for each snapper
configuration. You can select multiple configurations
(e.g. -c "root" -c "home"; --config root --config home)
--config-postfix <name> Specify a postfix that will be appended to the destination snapper config name.
--dry-run perform a trial run (no changes are written).
--mediapool Specify the name of the tape MediaPool
-n, --noconfirm Do not ask for confirmation for each configuration. Will still prompt for backup
--nonotify Disable graphical notification (via dbus)
--nopv Disable graphical progress output (disable pv)
--noionice Disable setting of I/O class and priority options on target
-r, --remote <address> Send the snapshot backup to a remote machine. The snapshot will be sent via ssh
You should specify the remote machine's hostname or ip address. The 'root' user
must be permitted to login on the remote machine
-p, --port <port> The remote port
-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
-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)
--version show program version
## Erster Sicherungslauf
Haben Sie bisher noch niemals auf ein Ziel-Gerät gesichert (first run), wird
`dsnap-sync` für die Erstellung der notwendigen Ziel Dateisystem-Strukturen
sorgen. Folgende Sicherungstypen werden unterschieden:
* btrfs-snapshots
Dieser Sicherungstyp ist der Systemstandard. Bei einem btrfs-snapshot
wird `dsnap-sync` verwendet, um bestehende `snapper` Konfigurationen
der Quelle auf ein Ziel-Gerät zu synchronisieren.
Auf dem Ziel-Gerät wird eine `snapper` Struktur falls erforderlich
neu erstellt. Dies beinhaltet die Erstellung von Ziel-Dateisystem Pfaden,
als auch die Erstellung der snapper Konfiguraktion unter Verwendung eines
Templates (`/etc/snapper/config-templates/dsnap-sync`).
Um eindeutige Namen bei der Nutzung von Konfiguration sicherzustellen,
wird `dsnap-sync` den Host-Namen des Quell-Systems an den Konfigurationsname
auf dem Ziel-System anhängen. Sie können dieses Verhalten durch eine
Konfigurations-Option anpassen (`--config-postfix`).
Folgende Parameter werden vom Template `dsnap-sync` an die aktive
Konfiguration vererbt:
* Neue Snapshots als Type 'single' markieren
* Neue Snapshots mit dem Clean-Algorithmus 'timeline' markieren
* die Konfigurationsoption 'CONFIG-TYPE=child' setzen
* die Konfigurationsoption 'TIMELINE_CREATE=no' setzen
* die Konfigurationsoption 'TIMELINE_CLEANUP=yes' setzen
Bitte passen sie diese Einstellungen auf Ihre Bedürfnisse an.
* btrfs-clone
Dieser Sicherungstyp ermöglicht die Duplizierung einer bereits
existierenden `snapper` Konfiguration innerhalb eines Quell-Systems.
Sinnvoll ist dies Funktionalität, wenn die auf dem Quell-System
die gewählte `snapper` Konfiguration auf externe Festplatten archiviert
werden sollen (disk-2-disk-2-disk). Auch diese Clone-Konfiguration
kann anschließend über die `snapper` Management-Tools verwaltet
werden. Das Ziel-Gerät muss daher zwingend ein btrfs Dateisystem
bereitstellen.
* btrfs-archive
Stellt das Ziel-Gerät kein btrfs Dateisystem bereit (e.g. ext4, xfs,
ltofs tapes), kann der Sicherungstyp btrfs-archive angewendet werden.
`dsnap-sync` wird anhand der Quell Snapshot-ID die Daten in ein
gewöhnliches Unterverzeichnis kopieren. Dieses Stamm-Verzeichnis
befindet sich unterhalb des Backup-Verzeichnisses auf dem Ziel-Gerät
(target-subdirectory). Unterhalb des 'target-subdirectory' erstellt
`dsnap-sync` in Analogie zur `snapper` Datenablabe folgende Struktur:
* 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`)
* 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
über den Sicherungstyp `btrfs-archive`.
## Automounter
`dsnap-sync` stellt alle verwendbaren btrfs Dateisysteme als Prozess-
Ziele bereit. Da Festplatten mit großen Speicher-Kapazitäten heutzutage
sehr preiswert angeboten werden, sind externe Festplatten als zusätzliche
Sicherungsziele üblich. Werden dies externen Festplatten aber nicht
während des Boot-Prozesses oder über dynamische Regeln eingebunden,
können sie von `dsnap-sync` nicht in der Auswahl-Funktion angeboten senden.
Es ist darüber hinaus durchaus sinnvoll, solche Festplatten nicht permanent
einzubinden (z.B. um die Risiken eines Malware-Angriffs zu minimieren, der
erreichbare Pfade verschlüsselt.)
Um externe Festplatten dynamisch mit einer persistenten Namens Syntax
einzubinden, können sie als 'automountbare Geräte' definiert werden.
Aktiviert wird der Automount-Prozess vor der Ziel-Auswahl zu aktivieren,
kannn der 'Mount-Point' als Option beim `dsnap-sync` Aufruf übergeben
werden (z.B: `--automount /var/backups/archive-disk1`).
Der [Abschnitt Automount](../../usr/share/doc/dsnap-sync/Examples.md#Automounter)
des Beispiel Dokuments enthält weitere Details.
## Tape-Administration / LTFS
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
(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:
`/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
"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
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
[LinearTapeFileSystem](https://github.com/LinearTapeFileSystem/ltfs).
## Mitarbeit
Hilfe ist sehr willkommen! Gerne könnt Ihr das Projekt forken und PR's einreichen,
um neue Funktion zu implementieren oder Fehler zu bereinigen.
Wenn Ihr an neuen Funktionen arbeiten wollt, schaut bitte auch in das TODO Dokument.
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
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
`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
Verwechslungen vermeinden.
## Lizenz
<!-- License source -->
[Logo-CC_BY]: https://i.creativecommons.org/l/by/4.0/88x31.png "Creative Common Logo"
[License-CC_BY]: https://creativecommons.org/licenses/by/4.0/legalcode "Creative Common License"
Diese Arbeit ist unter der [Creative Common License 4.0][License-CC_BY] lizensiert.
![Creative Common Logo][Logo-CC_BY]
© 2016, 2017 James W. Barnett;
© 2017 - 2018 Ralf Zerres

12
src/Makefile
View File

@@ -20,16 +20,20 @@ PKGNAME = dsnap-sync
PREFIX ?= /usr
SNAPPER_CONFIG ?= /etc/default/snapper
SNAPPER_TEMPLATES ?= /etc/snapper/config-templates
DSNAP_SYNC_EXAMPLES = /usr/share/doc/dsnap-sync
DSNAP_SYNC_EXAMPLES = usr/share/doc/dsnap-sync
BIN_DIR = $(DESTDIR)$(PREFIX)/bin
ETC_DIR = $(DESTDIR)/etc
SYSTEMD_DIR = $(DESTDIR)$(PREFIX)/lib/systemd/system
DOC_DIR = $(DESTDIR)$(PREFIX)/usr/share/doc/$(PKGNAME)
DOC_DIR = $(DESTDIR)$(PREFIX)/share/doc/dsnap-sync
.PHONY: install
install:
@./find_snapper_config || sed -i 's@^SNAPPER_CONFIG=.*@SNAPPER_CONFIG='$(SNAPPER_CONFIG)'@g' bin/$(PKGNAME)
@install -Dm755 bin/* -t $(BIN_DIR)/
@install -Dm644 ./$(SNAPPER_TEMPLATES)/* -t $(DESTDIR)/$(SNAPPER_TEMPLATES)/
@install -Dm644 ./$(DSNAP_SYNC_EXAMPLES)/* -t $(DESTDIR)/$(DOC_DIR)/
@install -dm755 $(ETC_DIR)/dsnap-sync
@install -Dm644 etc/dsnap-sync/* -t $(ETC_DIR)/dsnap-sync/
@install -dm755 $(ETC_DIR)/snapper/config-templates
@install -Dm644 etc/snapper/config-templates/* -t $(ETC_DIR)/snapper/config-templates/
@install -Dm644 $(DSNAP_SYNC_EXAMPLES)/* -t $(DOC_DIR)/

1285
src/bin/dsnap-sync Executable file → Normal file
View File

File diff suppressed because it is too large Load Diff

1737
src/bin/tape-admin Executable file
View File

File diff suppressed because it is too large Load Diff

38
src/etc/dsnap-sync/MediaPools.json Normal file
View File

@@ -0,0 +1,38 @@
{
"version": "0.0.4",
"_comment": "MediaPolicy: append, overwrite; Date values in UTC",
"MediaPools": "Media-Pools",
"MediaPool": [
{
"Name": "Pool-1",
"DefaultRetensionDays": "0",
"Tape-Type": "LTO7",
"_comment": "MediaPool append",
"Member": [
{ "VolumeName": "Tape-0001", "VolumeId": "000001", "Slot": "1", "MediaPolicy": "append", "RetensionDate": "20180824000000", "LastWrite": "20180824000000" },
{ "VolumeName": "Tape-0002", "VolumeId": "000002", "Slot": "2", "MediaPolicy": "append", "RetensionDate": "20180824000000", "LastWrite": "20180824000000" },
{ "VolumeName": "Tape-0003", "VolumeId": "000003", "Slot": "3", "MediaPolicy": "append", "RetensionDate": "20180824000000", "LastWrite": "20180824000000" },
{ "VolumeName": "Tape-0004", "VolumeId": "000004", "Slot": "4", "MediaPolicy": "append", "RetensionDate": "20180824000000", "LastWrite": "20180824000000" },
{ "VolumeName": "Tape-0005", "VolumeId": "000005", "Slot": "5", "MediaPolicy": "append", "RetensionDate": "20180824000000", "LastWrite": "20180824000000" },
{ "VolumeName": "Tape-0006", "VolumeId": "000006", "Slot": "6", "MediaPolicy": "append", "RetensionDate": "20180824000000", "LastWrite": "20180824000000" },
{ "VolumeName": "Tape-0007", "VolumeId": "000007", "Slot": "7", "MediaPolicy": "append", "RetensionDate": "20180824000000", "LastWrite": "20180824000000" },
{ "VolumeName": "Tape-0008", "VolumeId": "000008", "Slot": "8", "MediaPolicy": "append", "RetensionDate": "20180824000000", "LastWrite": "20180824000000" }
]
},
{
"Name": "Pool-2",
"DefaultRetensionDays": "7",
"Tape-Type": "LTO7",
"_comment": "MediaPool overwrite",
"Member": [
{ "VolumeName": "Tape-0009", "VolumeId": "000009", "Slot": "9", "MediaPolicy": "overwrite", "RetensionDate": "20180824000000", "LastWrite": "20180824000000" },
{ "VolumeName": "Tape-0010", "VolumeId": "000010", "Slot": "10", "MediaPolicy": "overwrite", "RetensionDate": "20180824000000", "LastWrite": "20180824000000" },
{ "VolumeName": "Tape-0011", "VolumeId": "000011", "Slot": "11", "MediaPolicy": "overwrite", "RetensionDate": "20180824000000", "LastWrite": "20180824000000" },
{ "VolumeName": "Tape-0012", "VolumeId": "000012", "Slot": "12", "MediaPolicy": "overwrite", "RetensionDate": "20180824000000", "LastWrite": "20180824000000" },
{ "VolumeName": "Tape-0013", "VolumeId": "000013", "Slot": "13", "MediaPolicy": "overwrite", "RetensionDate": "20180824000000", "LastWrite": "20180824000000" },
{ "VolumeName": "Tape-0014", "VolumeId": "000014", "Slot": "14", "MediaPolicy": "overwrite", "RetensionDate": "20180824000000", "LastWrite": "20180824000000" },
{ "VolumeName": "Tape-0015", "VolumeId": "000015", "Slot": "15", "MediaPolicy": "overwrite", "RetensionDate": "20180824000000", "LastWrite": "20180824000000" }
]
}
]
}

58
src/etc/snapper/config-templates/dsnap-sync
View File

@@ -1,58 +0,0 @@
###
# snapper template for dsnap-sync handling
###
# subvolume to snapshot
SUBVOLUME="/var/lib/dsnap-sync"
# filesystem type
FSTYPE="btrfs"
# users and groups allowed to work with config
ALLOW_USERS=""
ALLOW_GROUPS="adm"
# sync users and groups from ALLOW_USERS and ALLOW_GROUPS to .snapshots
# directory
SYNC_ACL="yes"
# start comparing pre- and post-snapshot in background after creating
# post-snapshot
BACKGROUND_COMPARISON="yes"
# run daily number cleanup
NUMBER_CLEANUP="no"
# limit for number cleanup
NUMBER_MIN_AGE="1800"
NUMBER_LIMIT="50"
NUMBER_LIMIT_IMPORTANT="10"
# "no": we will use systemd.timer
TIMELINE_CREATE="no"
# create cron based cleanup entries
# "no": we will use systemd.timer
TIMELINE_CLEANUP="no"
# snap-sync: timeline settings
TIMELINE_MIN_AGE="1800"
TIMELINE_LIMIT_HOURLY="1"
TIMELINE_LIMIT_DAILY="2"
TIMELINE_LIMIT_MONTHLY="1"
TIMELINE_LIMIT_YEARLY="1"
# cleanup empty pre-post-pairs
EMPTY_PRE_POST_CLEANUP="yes"
# limits for empty pre-post-pair cleanup
EMPTY_PRE_POST_MIN_AGE="1800"
# uncomment to exclude this subvol when calling
# snap-sync as timer unit
# SNAP_SUNC_EXCLUDE="yes"

228
usr/share/doc/dsnap-sync/Examples.md Normal file
View File

@@ -0,0 +1,228 @@
# Examples
## Automounter
`dsnap-sync` will take advantage of systemd automount units to incorporate external,
removable disks into the selection process for target devices.
### btrfs disk
Format the disk with btrfs tools to prepare it as a target.
The following example will reference to a btrfs disk and mount a given subvolume.
### systemd automount units
#### mount unit: var-backups-archive\x2ddisk1.mount
[Unit]
Description=Backup - Archiv-Disk 1
Documentation=man:systemd.mount(5) man:mount.btrfs(8)
DefaultDependencies=yes
[Mount]
What=UUID=977b4ecf-be67-4643-84f5-10b368c24d25
Where=/var/backups/archive-disk1
Type=btrfs
Options=defaults,subvol=@archive-disk1,compress=lzo
[Install]
WantedBy=multi-user.target
#### automount unit: var-backups-archive\x2ddisk1.automount
[Unit]
Description=Automount Backup - Archive-Disk 1
Documentation=man:systemd.automount(5)
[Automount]
Where=/var/backups/archive-disk1
TimeoutIdleSec=45
[Install]
WantedBy=multi-user.target
## `dsnap-sync` command line usage
### backup to local target
#### Default: no selections, run for all snapper configs
# dsnap-sync
#### Default: Select two configs, the backupdir and verbose output
# dsnap-sync --verbose --config root --config data2 --backupdir=toshiba_r700
#### Dry-run: Select config, select Target, as batchjob (--noconfirm)
# dsnap-sync -c root -s 265 --noconfirm --dry-run
### backup to remote target
`dsnap-sync` will rely on ssh access to the target host. For batch usage
make sure, that your public key is accepted for a remote login as user
'root'. You may have to adapt /root/.ssh/authorized_keys on the target host.
On your target host, you should also verify the availability of a
`dsnap-sync` config-template for snapper. A template `dsnap-sync`
is included in the package for your convenience.
#### Dryrun: Select remote host <ip/fqdn>, interactive, run for all configs
dsnap-sync --dry-run --remote <fqdn/ip>
Select target disk...
0) /var/lib/snap-sync (uuid=b5915f47-38a8-4b37-8de6-c8b15d9aba5a,subvolid=257,subvol=/var/lib/@snap-sync)
1) /var/backups/archive-disk4 (uuid=137b4a36-6e17-487b-a328-29b0d1e020c3,subvolid=257,subvol=/@dws-archive-disk4)
2) /var/backups/archive-disk3 (uuid=c9fcbfd3-6a1f-4b43-8176-b6f326bf46c7,subvolid=257,subvol=/@dws-archive-disk3)
3) /var/backups/archive-disk1 (uuid=977b4ecf-be67-4643-84f5-10b368c24d25,subvolid=257,subvol=/@dws-archive-disk1)
4) /var/backups/archive-disk2 (uuid=b68c8a31-9878-4ec1-b7ed-948de2125285,subvolid=257,subvol=/@dws-archive-disk2)
x) Exit
Enter a number: 1
### Dry-run with given Target for snapper config 'data2', no confirmations
#### Sync: Select config 'data2', remote host <ip/fqdn>, target '/var/lib/snap-sync', as batchjob (--noconfirm)
# dsnap-sync --config data2 --remote <fqdn/ip> --target /var/lib/snap-sync --batch --verbose
## systemd
`dsnap-sync` will structure all scheduling tasks while using systemd units.
To perform a backup process for just a single snapper configuration at a
given time, you have to define a pair of a systemd service unit and a
corresponding systemd timer unit.
Below we define a generic `dsnap-sync service unit` that should be located
at /etc/systemd/system. Following call will reference this template:
`systemd enable dsnap-sync@data2.service`
### service unit: `dsnap-sync@.service
[Unit]
Description=dsnap-sync backup for target %i
[Install]
WantedBy=multi-user.target
[Service]
Type=simple
ExecStart=/usr/bin/dsnap-sync \
--config %i \
--uuid 7360922b-c916-4d9f-a670-67fe0b91143c \
--subvolid 5 \
--remote backup-host
--batch
### overriding service unit: `dsnap-sync@data2.service`
Please remember, that the template example encode a given target
UUID and SUBVOLID. If you want the unit to serve individual parameter,
you have to override the it like:
`systemd edit dsnap-sync@data2.service`
Define a service paragraph, clean out the ExecStart= parameter and
refine a new ExedStart= parameter with the intended.
[Service]
ExecStart=
ExecStart=/usr/bin/dsnap-sync \
--config %i \
--target /var/lib/dsnap-sync \
--remote my-backup-host
--batch
### timer unit: `dsnap-sync@.timer`
Below we define a generic `dsnap-sync timer unit` that should be located
at /etc/systemd/system.
[Unit]
Description=dsnap-sync weekly backup
[Timer]
OnCalendar=weekly
AccuracySec=12h
Persistent=true
[Install]
WantedBy=timers.target
Following call will reference this template:
`systemd enable dsnap-sync@data2.timer`
## snapper extensions
For any new `dsnap-sync` btrfs-snapshot a new target snapper structure is need,
if the target backups should be managable via snapper.
`dsnap-sync` will create this structure as needed. During the creation it
will reference to a template called `dsnap-sync`. Please adapt it
if your milage varies.
### `dsnap-sync` template
###
# snapper template for dsnap-sync handling
###
# subvolume to snapshot
SUBVOLUME="/var/lib/dsnap-sync"
# filesystem type
FSTYPE="btrfs"
# users and groups allowed to work with config
ALLOW_USERS=""
ALLOW_GROUPS="adm"
# sync users and groups from ALLOW_USERS and ALLOW_GROUPS to .snapshots
# directory
SYNC_ACL="yes"
# start comparing pre- and post-snapshot in background after creating
# post-snapshot
BACKGROUND_COMPARISON="yes"
# handele NUMBER_CLEANUP via systemd, if a timer unit is active
NUMBER_CLEANUP="yes"
# limit for number cleanup
NUMBER_MIN_AGE="1800"
NUMBER_LIMIT="52"
NUMBER_LIMIT_IMPORTANT="12"
# handle TIMELINE via systemd, if a timer unit is active
TIMELINE_CREATE="yes"
# create a systemd.timer unit to handle TIMELINE cleanup
TIMELINE_CLEANUP="yes"
# timeline settings
TIMELINE_MIN_AGE="1800"
TIMELINE_LIMIT_HOURLY="1"
TIMELINE_LIMIT_DAILY="14"
TIMELINE_LIMIT_MONTHLY="11"
TIMELINE_LIMIT_YEARLY="2"
# cleanup empty pre-post-pairs
EMPTY_PRE_POST_CLEANUP="yes"
# limits for empty pre-post-pair cleanup
EMPTY_PRE_POST_MIN_AGE="1800"
# uncomment to exclude this subvol when calling
# snap-sync as timer unit
# SNAP_SYNC_EXCLUDE="yes"
# Valid CONFIG_TYPE: archive, child, parent
# CONFIG_TYPE="archive" -> if synced, stream snapshot to a non btrfs filesystem
# CONFIG_TYPE="child" -> if synced, stream snapshot to a given CHILD_CONFIG name
CONFIG_TYPE="child"
#CHILD_CONFIG=<child config name>
#PARENT_CONFIG=<parent config name>

1
usr/share/doc/dsnap-sync/README.md Symbolic link
View File

@@ -0,0 +1 @@
../../../../README.md

1
usr/share/doc/dsnap-sync/TODO.md Symbolic link
View File

@@ -0,0 +1 @@
../../../../TODO.md