patrick/zfs_autobackup
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

update

Edwin Eefting
2022-01-07 13:36:40 +01:00
parent 8df85077a7
commit ce8a6497d2
1 changed files with 23 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
Thinner.md

@ -6,26 +6,10 @@ The thinner operates "stateless": There is nothing in the name or properties of
Note that the thinner will ONLY destroy snapshots that are matching the naming pattern of zfs-autobackup. If you use `--other-snapshots`, it wont destroy those snapshots after replicating them to the target. Note that the thinner will ONLY destroy snapshots that are matching the naming pattern of zfs-autobackup. If you use `--other-snapshots`, it wont destroy those snapshots after replicating them to the target.
## Destroying missing datasets
When a dataset has been destroyed or deselected on the source, but still exists on the target we call it a missing dataset. Missing datasets will be still thinned out according to the schedule.
The final snapshot will never be destroyed, unless you specify a **deadline** with the `--destroy-missing` option:
In that case it will look at the last snapshot we took and determine if is older than the deadline you specified. e.g: `--destroy-missing 30d` will start destroying things 30 days after the last snapshot.
### After the deadline
When the deadline is passed, all our snapshots, except the last one will be destroyed. Irregardless of the normal thinning schedule.
The dataset has to have the following properties to be finally really destroyed:
* The dataset has no direct child-filesystems or volumes.
* The only snapshot left is the last one created by zfs-autobackup.
* The remaining snapshot has no clones.
## Thinning schedule ## Thinning schedule
The thinning schedule is specified via the `--keep-source=...` and `--keep-target=...` parameters.
The default thinning schedule is: `10,1d1w,1w1m,1m1y`. The default thinning schedule is: `10,1d1w,1w1m,1m1y`.
The schedule consists of multiple rules separated by a `,` The schedule consists of multiple rules separated by a `,`
@ -47,10 +31,12 @@ The format of the other rules is: `<Interval><TTL>`.
Since this might sound very complicated, the `--verbose` option will show you what it all means: Since this might sound very complicated, the `--verbose` option will show you what it all means:
```console ```console
...
[Source] Keep the last 10 snapshots. [Source] Keep the last 10 snapshots.
[Source] Keep every 1 day, delete after 1 week. [Source] Keep every 1 day, delete after 1 week.
[Source] Keep every 1 week, delete after 1 month. [Source] Keep every 1 week, delete after 1 month.
[Source] Keep every 1 month, delete after 1 year. [Source] Keep every 1 month, delete after 1 year.
...
``` ```
A snapshot will only be destroyed if it not needed anymore by ANY of the rules. A snapshot will only be destroyed if it not needed anymore by ANY of the rules.
@ -63,7 +49,25 @@ However, its no problem if you run it more or less often than that: The thinner
If you want to keep as few snapshots as possible, just specify 0. (`--keep-source=0` for example) If you want to keep as few snapshots as possible, just specify 0. (`--keep-source=0` for example)
If you want to keep ALL the snapshots, just specify a very high number. If you want to keep ALL the snapshots, just specify a high number.
## Destroying missing datasets
When a dataset has been destroyed or deselected on the source, but still exists on the target we call it a missing dataset. Missing datasets will be still thinned out according to the schedule.
The final snapshot will never be destroyed, unless you specify a **deadline** with the `--destroy-missing` option:
In that case it will look at the last snapshot we took and determine if is older than the deadline you specified. e.g: `--destroy-missing 30d` will start destroying things 30 days after the last snapshot.
### After the deadline
When the deadline is passed, all our snapshots, except the last one will be destroyed. Irregardless of the normal thinning schedule.
The dataset has to have the following properties to be finally really destroyed:
* The dataset has no direct child-filesystems or volumes.
* The only snapshot left is the last one created by zfs-autobackup.
* The remaining snapshot has no clones.
## Technical details about the Thinner ## Technical details about the Thinner