Thanks.
My understanding is that when I execute zfs snapshot -r zroot@backup1 at the first time, I will create a full snapshot, and then execute zfs snapshot -r zroot@backup* later , I will get incremental snapshots, is it right?
No, that's incorrect.
Also see
zfs(8) on snapshots:
Code:
A snapshot is a read-only copy of a file system or volume. Snapshots can
be created extremely quickly, and initially consume no additional space
within the pool. As data within the active dataset changes, the snapshot
consumes more data than would otherwise be shared with the active
dataset.
A snapshot is just what it's name implies: a snapshot of the
current state of your filesystem. After you make a snapshot it'll be empty and as data changes it gets more filled up.
So if you make a second snapshot all you're doing is saving the new state your filesystem is in at that time. This has nothing to do with incremental backups or anything.
For example:
Code:
$ zfs list -rt all zroot/home
NAME USED AVAIL REFER MOUNTPOINT
zroot/home 26.1G 51.2G 25.9G /home
zroot/home@230718 10.9M - 26.1G -
zroot/home@240718 10.8M - 26.1G -
zroot/home@250718 10.8M - 26.1G -
zroot/home@260718 10.9M - 26.1G -
zroot/home@270718 10.9M - 26.1G -
zroot/home@280718 10.9M - 25.9G -
zroot/home@290718 430K - 25.9G -
There's a reason why
290718 is only
430K at this time: because nothing has happened on the filesystem so far.
If I want to do a full backup every Monday and save it to another server, like this zfs send -Rv zroot@backup1 | gzip > ssh host2 /root/backup1.gz , then next Monday, how do I create a full snapshot instead of an incremental snapshot?
Once again, see
zfs(8). You'd need
-i to (quote): "
Generate an incremental stream from the first snapshot (the incremental source) to the second snapshot (the incremental target).". Since you're not using
-i why assume that you'd be creating an incremental backup? You're not.
It even says so in the main description (quote): "
By default, a full stream is generated.".
The commands above merely send the state of the (whole) filesystem as it was during the creation of the snapshot. As such: it'll be a full backup. Context is a thing here and within ZFS some aspects behave a bit differently. Having said that I also wonder if you really want to use
-R if all you care for is a full backup of your data. ZFS sends a full stream by default, so there's no direct need.
-R is only useful if you want a full ZFS filesystem replication. Note: ZFS
filesystem, so not just the data that's on it. Using
-R implies that you want to save the full state of the filesystem, including all relevant snapshots. Yet that means that your backup doesn't merely cover the current state of your data, it also includes all of the snapshots. Which seems highly counter productive to me, depending on your setup of course.
Finally... How did you came up with this:
zfs send -Rv zroot@backup1 | gzip > ssh host2 /root/backup1.gz?
That obviously won't work, from
ssh(1):
Code:
SYNOPSIS
ssh [-1246AaCfGgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-E log_file] [-e escape_char]
[-F configfile] [-I pkcs11] [-i identity_file]
[-J [user@]host[:port]] [-L address] [-l login_name] [-m mac_spec]
[-O ctl_cmd] [-o option] [-p port] [-Q query_option] [-R address]
[-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]]
[user@]hostname [command]
Note how it mentions
[command] at the end? This means that
ssh expects a command, not a file. This is also showcased in
zfs(8). Details are important on a Unix-like environment, you should try not to gloss over them like that.
And you're missing out on
many of those details. Because... what do you think
> does? From
sh(1): "
[n]> file redirect stdout (or file descriptor n) to file".
So what you'd be doing is create a file called
ssh which would contain your ZFS snapshot data.
This is what I'd do:
zfs send zroot@backup | gzip | ssh backup@host2 "dd of=/opt/backups/backup1.zfs.gz".
I'm sorry that my post may start to look like a summing up on dozens of failures as if I'm trying to rub it in. Actually... that last part is somewhat true, I am doing just that, but this is not to anyones amusement, only to warn you that there are some
serious problems here. If you just go along in the direction you're headed then, no joking, I foresee your system getting taken over sooner or later (
note: there are some assumptions at work here on my end, I'm not saying this is going to happen but there are some signs of major risks involved here).
See: the command you showed us earlier almost makes it look as if you can "just" login to a remote backup host as the
root user, even without using any passwords. If that is your current situation then that's
seriously bad. Especially if this server can somehow be reached from the outside and is using password authentication (hence my previous comments about assumptions).
At best you'd make a non-privileged backup user, give it a decent password (better yet: set up key based authentication for SSH) and obviously give it write access to a specific backup area. Then use the command I mentioned earlier.
Hope this can give you some ideas.
