third-party-mirrors/zfs_autobackup
1
0
Fork 1
mirror of https://github.com/psy0rz/zfs_autobackup.git synced 2025-04-11 22:40:01 +03:00
Code Issues Actions Packages Projects Releases Wiki Activity

fix markup

Browse Source
This commit is contained in:
Edwin Eefting 2020-02-19 20:10:07 +01:00
parent c6d45e4441
commit 1dd683c1e2
1 changed files with 62 additions and 76 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

138
README.md
View File

@ -1,14 +1,12 @@
ZFS autobackup v3 - TEST VERSION
================================
# ZFS autobackup v3 - TEST VERSION
New in v3:
----------
## New in v3
* Complete rewrite, cleaner object oriented code.
* Python 3 and 2 support.
* Backwards compatible with your current backups and parameters.
* Progressive thinning (via a destroy schedule. default schedule should be fine for most people)
* Cleaner output, with optional color support (pip install colorama).
* Cleaner output, with optional color support (pip install colorama).
* Clear distinction between local and remote output.
* Summary at the beginning, displaying what will happen and the current thinning-schedule.
* More effient destroying/skipping snaphots on the fly. (no more space issues if your backup is way behind)
@ -19,13 +17,12 @@ New in v3:
* Prepared for future enhanchements.
* Supports raw backups for encryption.
Introduction
============
## Introduction
ZFS autobackup is used to periodicly backup ZFS filesystems to other locations. This is done using the very effcient zfs send and receive commands.
It has the following features:
* Works across operating systems: Tested with Linux, FreeBSD/FreeNAS and SmartOS.
* Works in combination with existing replication systems. (Like Proxmox HA)
* Automatically selects filesystems to backup by looking at a simple ZFS property. (recursive)
@ -34,7 +31,7 @@ It has the following features:
* Backup local data on the same server.
* "push" local data to a backup-server via SSH.
* "pull" remote data from a server via SSH and backup it locally.
* Or even pull data from a server while pushing the backup to another server.
* Or even pull data from a server while pushing the backup to another server.
* Can be scheduled via a simple cronjob or run directly from commandline.
* Supports resuming of interrupted transfers. (via the zfs extensible_dataset feature)
* Backups and snapshots can be named to prevent conflicts. (multiple backups from and to the same filesystems are no problem)
@ -49,16 +46,16 @@ It has the following features:
* Written in python and uses zfs-commands, no 3rd party dependency's or libraries.
* No separate config files or properties. Just one zfs_autobackup-command you can copy/paste in your backup script.
Installation
============
```
(tbd)
## Installation
```shell session
sadfas
```
Usage
=====
```
## Usage
```shell session
usage: zfs_autobackup [-h] [--ssh-source SSH_SOURCE] [--ssh-target SSH_TARGET]
[--keep-source KEEP_SOURCE] [--keep-target KEEP_TARGET]
[--no-snapshot] [--allow-empty] [--ignore-replicated]
@ -149,18 +146,17 @@ failures at that end. Also the exit code will indicate the number of failures.
```
Backup example
==============
## Backup example
In this example we're going to backup a machine called `pve` to our backupserver.
Its important to choose a unique and consistent backup name. In this case we name our backup: `offsite1`.
Select filesystems to backup
----------------------------
### Select filesystems to backup
On the source zfs system set the ```autobackup:offsite``` zfs property to true:
```
```shell session
[root@pve ~]# zfs set autobackup:offsite1=true rpool
[root@pve ~]# zfs get -t filesystem,volume autobackup:offsite1
NAME PROPERTY VALUE SOURCE
@ -174,7 +170,8 @@ rpool/swap autobackup:offsite1 true
```
Because we dont want to backup everything, we can exclude certain filesystem by setting the property to false:
```
```shell session
[root@pve ~]# zfs set autobackup:offsite1=false rpool/swap
[root@pve ~]# zfs get -t filesystem,volume autobackup:offsite1
NAME PROPERTY VALUE SOURCE
@ -187,17 +184,17 @@ rpool/swap autobackup:offsite1 false
...
```
### Running zfs_autobackup
Running zfs_autobackup
----------------------
There are 2 ways to run the backup, but the endresult is always the same. Its just a matter of security (trust relations between the servers) and preference.
First install the ssh-key on the server that you specify with --ssh-source or --ssh-target.
Method 1: Run the script on the backup server and pull the data from the server specfied by --ssh-source. This is usually the preferred way and prevents a hacked server from accesing the backup-data:
```
#### Method 1: Run the script on the backup server and pull the data from the server specfied by --ssh-source. This is usually the preferred way and prevents a hacked server from accesing the backup-data
```shell session
[root@backup ~]# zfs_autobackup --ssh-source pve.server.com offsite1 backup/pve --progress --verbose --resume
#### Settings summary
[Source] Datasets on: pve.server.com
[Source] Keep the last 10 snapshots.
@ -240,9 +237,10 @@ Method 1: Run the script on the backup server and pull the data from the server
```
Method 2: Run the script on the server and push the data to the backup server specified by --ssh-target:
```
```shell session
[root@pve ~]# zfs_autobackup --ssh-target backup.server.com offsite1 backup/pve --progress --verbose --resume
#### Settings summary
[Source] Datasets are local
[Source] Keep the last 10 snapshots.
@ -261,21 +259,20 @@ Method 2: Run the script on the server and push the data to the backup server sp
```
Tips
====
## Tips
* Use ```--verbose``` to see details, otherwise zfs_autobackup will be quiet and only show errors, like a nice unix command.
* Use ```--debug``` if something goes wrong and you want to see the commands that are executed. This will also stop at the first error.
* Use ```--resume``` to be able to resume aborted backups. (not all zfs versions support this)
* Set the ```readonly``` property of the target filesystem to ```on```. This prevents changes on the target side. If there are changes the next backup will fail and will require a zfs rollback. (by using the --rollback option for example)
* Use ```--clear-refreservation``` to save space on your backup server.
* Use ```--clear-mountpoint``` to prevent the target server from mounting the backupped filesystem in the wrong place during a reboot.
Speeding up SSH and prevent connection flooding
-----------------------------------------------
* Use ```--verbose``` to see details, otherwise zfs_autobackup will be quiet and only show errors, like a nice unix command.
* Use ```--debug``` if something goes wrong and you want to see the commands that are executed. This will also stop at the first error.
* Use ```--resume``` to be able to resume aborted backups. (not all zfs versions support this)
* Set the ```readonly``` property of the target filesystem to ```on```. This prevents changes on the target side. If there are changes the next backup will fail and will require a zfs rollback. (by using the --rollback option for example)
* Use ```--clear-refreservation``` to save space on your backup server.
* Use ```--clear-mountpoint``` to prevent the target server from mounting the backupped filesystem in the wrong place during a reboot.
### Speeding up SSH and prevent connection flooding
Add this to your ~/.ssh/config:
```
```shell session
Host *
ControlPath ~/.ssh/control-master-%r@%h:%p
ControlMaster auto
@ -286,12 +283,11 @@ This will make all your ssh connections persistent and greatly speed up zfs_auto
Thanks @mariusvw :)
Specifying ssh port or options
------------------------------
### Specifying ssh port or options
The correct way to do this is by creating ~/.ssh/config:
```
```shell session
Host smartos04
Hostname 1.2.3.4
Port 1234
@ -305,87 +301,77 @@ Also uses compression on slow links.
Look in man ssh_config for many more options.
Troubleshooting
===============
## Troubleshooting
`cannot receive incremental stream: invalid backup stream`
> ### cannot receive incremental stream: invalid backup stream
This usually means you've created a new snapshot on the target side during a backup.
* Solution 1: Restart zfs_autobackup and make sure you dont use --resume. If you did use --resume, be sure to "abort" the recveive on the target side with zfs recv -A.
* Solution 2: Destroy the newly created snapshot and restart zfs_autobackup.
This usually means you've created a new snapshot on the target side during a backup:
* Solution 1: Restart zfs_autobackup and make sure you dont use --resume. If you did use --resume, be sure to "abort" the recveive on the target side with zfs recv -A.
* Solution 2: Destroy the newly created snapshot and restart zfs_autobackup.
`internal error: Invalid argument`
> ### internal error: Invalid argument
In some cases (Linux -> FreeBSD) this means certain properties are not fully supported on the target system.
Try using something like: --filter-properties xattr
Restore example
===============
## Restore example
Restoring can be done with simple zfs commands. For example, use this to restore a specific SmartOS disk image to a temporary restore location:
```
```shell session
root@fs1:/home/psy# zfs send fs1/zones/backup/zfsbackups/smartos01.server.com/zones/a3abd6c8-24c6-4125-9e35-192e2eca5908-disk0@smartos01_fs1-20160110000003 | ssh root@2.2.2.2 "zfs recv zones/restore"
```
After that you can rename the disk image from the temporary location to the location of a new SmartOS machine you've created.
## Monitoring with Zabbix-jobs
Monitoring with Zabbix-jobs
===========================
You can monitor backups by using my zabbix-jobs script. (https://github.com/psy0rz/stuff/tree/master/zabbix-jobs)
You can monitor backups by using my zabbix-jobs script. (<https://github.com/psy0rz/stuff/tree/master/zabbix-jobs>)
Put this command directly after the zfs_backup command in your cronjob:
```
```shell session
zabbix-job-status backup_smartos01_fs1 daily $?
```
This will update the zabbix server with the exitcode and will also alert you if the job didnt run for more than 2 days.
Backuping up a proxmox cluster with HA replication
==================================================
## Backuping up a proxmox cluster with HA replication
Due to the nature of proxmox we had to make a few enhancements to zfs_autobackup. This will probably also benefit other systems that use their own replication in combination with zfs_autobackup.
All data under rpool/data can be on multiple nodes of the cluster. The naming of those filesystem is unique over the whole cluster. Because of this we should backup rpool/data of all nodes to the same destination. This way we wont have duplicate backups of the filesystems that are replicated. Because of various options, you can even migrate hosts and zfs_autobackup will be fine. (and it will get the next backup from the new node automaticly)
In the example below we have 3 nodes, named h4, h5 and h6.
The backup will go to a machine named smartos03.
Preparing the proxmox nodes
---------------------------
### Preparing the proxmox nodes
On each node select the filesystems as following:
```
```shell session
root@h4:~# zfs set autobackup:h4_smartos03=true rpool
root@h4:~# zfs set autobackup:h4_smartos03=false rpool/data
root@h4:~# zfs set autobackup:data_smartos03=child rpool/data
```
* rpool will be backuped the usual way, and is named h4_smartos03. (each node will have a unique name)
* rpool/data will be excluded from the usual backup
* The CHILDREN of rpool/data be selected for a cluster wide backup named data_smartos03. (each node uses the same backup name)
Preparing the backup server
---------------------------
### Preparing the backup server
Extra options needed for proxmox with HA:
* --no-holds: To allow proxmox to destroy our snapshots if a VM migrates to another node.
* --ignore-replicated: To ignore the replicated filesystems of proxmox on the receiving proxmox nodes. (e.g: only backup from the node where the VM is active)
I use the following backup script on the backup server:
```
```shell session
for H in h4 h5 h6; do
echo "################################### DATA $H"
#backup data filesystems to a common place
@ -397,4 +383,4 @@ for H in h4 h5 h6; do
./zfs_autobackup --ssh-source root@$H $H""_smartos03 zones/backup/zfsbackups/$H --verbose --clear-refreservation --clear-mountpoint --resume --ignore-transfer-errors $@
zabbix-job-status backup_$H""_smartos03 daily $? >/dev/null 2>/dev/null
done
```
```