zfs-concepts(7):Guys is there a way to check the progress of a snapshot Or any other way to know when it is done?
Snapshots
A snapshot is a read-only copy of a file system or volume. Snapshots can
be created extremely quickly, [...]
zfs-concepts(7):
So, I'd think when you get a success return value, you're done.Code:Snapshots A snapshot is a read-only copy of a file system or volume. Snapshots can be created extremely quickly, [...]
As mer stated: not sure exactly what you mean. I'm guessing you have a different idea of how the creation of a snapshot is implemented (a snapshot deletion is definitely different). Perhaps have a look at:
- How ZFS snapshots really work and why they perform well (usually) - by Matt Ahrens, BSDCan 2019
#!/usr/bin/env bash
# Vars
_date=`date "+%Y-%m-%d"`
_disk_dest="/tmp/bkp"
_bkp_dest="$_disk_dest/$_date"
_pool="tank1"
_snap="zhome@`hostname`_$_date"
_hbase="tank1/zhome@base-FreeBaSeD-T430_2023-06-30"
# Create directory destination
mkdir -p "${_bkp_dest}/zhome"
# Functions
bkp_files(){
zfs snapshot "${_pool}"/"${_snap}" && \
zfs send -I "${_hbase}" \
tank1/"${_snap}" | \
xz -9 > /mnt/bkp/"${_date}"/zhome.xz
}
...
Try running it with bash -x to review the built commands, but it looks like your send will be -I tank1/zhome@base… tank1/home@.. ( where zhome!=home, and the send will fail.)So something like this should work as expected?
Bash:#!/usr/bin/env bash # Vars _date=`date "+%Y-%m-%d"` _disk_dest="/tmp/bkp" _bkp_dest="$_disk_dest/$_date" _pool="tank1" _snap="home@`hostname`_$_date" _hbase="tank1/zhome@base-FreeBaSeD-T430_2023-06-30" # Create directory destination mkdir -p "${_bkp_dest}/zhome" # Functions bkp_files(){ zfs snapshot "${_pool}"/"${_snap}" && \ zfs send -I "${_hbase}" \ tank1/"${_snap}" | \ xz -9 > /mnt/bkp/"${_date}"/zhome.xz } ...
You mean
xz
?Thank you, I fixed the var. But my question is regarding theTry running it with bash -x to review the built commands, but it looks like your send will be -I tank1/zhome@base… tank1/home@.. ( where zhome!=home, and the send will fail.)
&&
, if the zfs send
would wait for the zfs snapshot
to finish in the background first. And I say background because after I run the snapshot command, I usually check with zfs list -t snapshot
and the size of the be usually takes a few minutes to reach the real size and stops grow.Based on 3.2.4 Lists of Commands:[...] But my question is regarding the&&
, if thezfs send
would wait for thezfs snapshot
to finish in the background first. And I say background because after I run the snapshot command, I usually check withbectl list
and the size of the be usually takes a few minutes to reach the real size and stops grow.
An AND list has the form
command1 && command2
command2 is executed if, and only if, command1 returns an exit status of zero (success).
bectl list
only lists BEs, unless used in conjuction with the -s option—see bectl(8). What is your exact bectl command?Sorry, I meantBased on 3.2.4 Lists of Commands:
I (not a bash expert) would say that is exactly as intended.Rich (BB code):An AND list has the form command1 && command2 command2 is executed if, and only if, command1 returns an exit status of zero (success).
I don't quite understand your "background" remark. After a snapshot creation,bectl list
only lists BEs, unless used in conjuction with the -s option—see bectl(8). What is your exact bectl command?
zfs list -t snapshot
, bectl
it is a part of the second half of the sh (out of the scope of this thread).You meanxz
?
Thank you, I fixed the var. But my question is regarding the&&
, if thezfs send
would wait for thezfs snapshot
to finish in the background first. And I say background because after I run the snapshot command, I usually check withzfs list -t snapshot
and the size of the be usually takes a few minutes to reach the real size and stops grow.
pv
is probably the best way to monitor progress of zfs send
.xz -9
is going to slow things down a lot. Unless absolute maximum compression is required in real time, I'd consider a different approach (write output to a file, then either nohup
and background xz
, or scan for compression candidates from cron
at 2am).EXTSN1=$(GetDiskSerialNumber $EXTDISK1 12)
gpart destroy -F $EXTDISK1
gpart create -s gpt $EXTDISK1
gpart add -t freebsd-zfs -l X0:$EXTSN1 $EXTDISK1
zpool create -f offsite /dev/gpt/X0:$EXTSN1
zfs set compression=lz4 offsite
zfs snapshot -r tank@replica
zfs unmount offsite
size=$(zfs send -nP -R tank@replica | grep "^size" | sed -e "s/size[ $TAB]*//")
IsPosNZint "$size" || Barf "bad send size for tank@replica1: \"$size\""
zfs send -R tank@replica | pv -s $size -ptebarT | zfs receive -Fdu offsite
zfs destroy -r tank@replica
zfs list -t snapshot
zpool export offsite
zfs send -nP
to get an estimate of the volume of data to be sent, and then pv
to report on actual progress.Yep, typo sorryYou meanxz
?
I encourage you to review the replies above.I'm thinking about make a video showing what I'm talking about. It will give a better insight.
To be fair, I've seen it take several seconds on a very busy (and/or slow storage) pool. But still, once the `zfs snapshot` command returns with exit status 0, you're good to go. (I suppose it can fail if the pool is really full, or in read-only mode, but that should be a giant clue to go fix something)Your original question was effectively how long a snapshot takes. The answer is near-instantaneous.
To be fair, I've seen it take several seconds on a very busy (and/or slow storage) pool. But still, once the `zfs snapshot` command returns with exit status 0, you're good to go.
All previous modifications by successful system calls to the file system are part of the snapshots.