Re: Amanda and ZFS
Anthony Worrall wrote: Hi unfortunately zfsdump, or "zfs send" as it is now, does not relate to ufsdump in any way :-( [...] I wrote a script to use this but I had a problem getting estimates for the incremental snapshots. I have used this script, picked from the list's archive, for about 18 months and I indeed had to make some small changes related to these estimates. FWIW, what I use is attached (does the list accept attachements ?) I can not see how amrecover would not be able to restore from the snapshot as it does not know the format used. In fact there is no way that I know of to extract a file from the snapshot sort of recovering the whole snapshot. This is probably not too much of a big issue as the tape backup is only needed for disaster recover and snapshot can be used for file recovery. amrestore could be used with "zfs receive" to recover the snapshot. Test restores went fine. Restoring to an incremental level is a little awkward (one has to rename each restored snaphot before receiving the next one) but certainly cleaner than doing it from an ufsdump with its potential resurrected/moved files problems. #!/bin/pfksh #need to use pfksh so that zfs can be run ZFS=/usr/sbin/zfs #Get the last argument for FS in $@; do echo $FS > /dev/null done #Check if the filesystem is zfs or ufs res=`$ZFS list | /usr/xpg4/bin/egrep "${FS}$"` if [ $? -eq 0 ]; then DEV=`echo $res | awk '{ print $1}'` ESTIMATE=0 LEVEL="unknown" UPDATE=0 case $1 in *0*) LEVEL=0;; *1*) LEVEL=1;; *2*) LEVEL=2;; *3*) LEVEL=3;; *4*) LEVEL=4;; *5*) LEVEL=5;; *6*) LEVEL=6;; *7*) LEVEL=7;; *8*) LEVEL=8;; *9*) LEVEL=9;; *) echo level NOT specfied; exit -1;; esac case $1 in *S*) ESTIMATE=1;; esac case $1 in *u*) UPDATE=1;; esac $ZFS list -H -t snapshot | /usr/xpg4/bin/grep -q [EMAIL PROTECTED] if [ $? -eq 0 ]; then $ZFS destroy [EMAIL PROTECTED] fi $ZFS snapshot [EMAIL PROTECTED] # make sure all the snapshots up to $LEVEL exist n=1 while [ $n -le $LEVEL ]; do $ZFS list -H -t snapshot | /usr/xpg4/bin/grep -q [EMAIL PROTECTED] if [ $? -ne 0 ]; then LEVEL=$(( $n - 1 )) break fi n=$(($n+1)) done full=`$ZFS list -H -o refer [EMAIL PROTECTED] #convert returned size into kilobytes case $full in *K) full=`echo $full | sed -e 's/K//'`;; *M) full=`echo $full | sed -e 's/M//'`; full=$(( $full * 1024 ));; *G) full=`echo $full | sed -e 's/G//'`; full=$(( $full * 1024 * 1024));; esac if [ $LEVEL -gt 0 ]; then incr=`$ZFS list -H -o refer [EMAIL PROTECTED] case $incr in *K) incr=`echo $incr | sed -e 's/K//'`;; *M) incr=`echo $incr | sed -e 's/M//'`; incr=$(( $incr * 1024 ));; *G) incr=`echo $incr | sed -e 's/G//'`; incr=$(( $incr * 1024 * 1024));; esac size=$(( $full - $incr )) # $full can be less than $incr if we recently removed data # zfs send -i will no be exactly 0, but relatively small if [ $size -lt 0 ]; then size=0 fi else size=$full fi size=$(( $size + 16 )) if [ $ESTIMATE == 1 ]; then # echo "doing Estimate $DEV at level $LEVEL" >&2 size=$(( $size * 1024 )) echo $size $ZFS destroy [EMAIL PROTECTED] else # echo "Dumping $DEV at level $LEVEL" >&2 if [ $LEVEL -eq 0 ]; then $ZFS send [EMAIL PROTECTED] else $ZFS send -i [EMAIL PROTECTED] [EMAIL PROTECTED] fi block=$(( $size * 2 )) MB=$(( $size / 1024 )) echo "DUMP: $block blocks (${MB}MB)" >&2 if [ $UPDATE -eq 1 ]; then for snap in `$ZFS list -H -t snapshot | awk '{print $1}' | egrep ${DEV}@"[1-9]$"`; do n=`echo $snap | cut -f2 [EMAIL PROTECTED] if [ $n -gt $LEVEL ]; then $ZFS destroy $snap fi done n=$(( $LEVEL + 1 )) $ZFS rename [EMAIL PROTECTED] [EMAIL PROTECTED] else $ZFS destroy [EMAIL PROTECTED] fi fi else /usr/lib/fs/ufs/ufsdump $* fi
Re: Amanda and ZFS
On Fri, Apr 25, 2008 at 01:36:35PM -0600, John E Hein wrote: > Jon LaBadie wrote at 13:57 -0400 on Apr 25, 2008: > > Though I've not tried it, it should. > > > > I base that on the description of the command > > > > /usr/sbin/ufsdump [options] [arguments] files_to_dump > > > > and the belief that the include directive merely provides the args > > corresponding to "files_to_dump". > > Ah. Okay. That's a solaris ufsdump feature... linux, too, maybe > others. It won't work for the BSDs (filesystem only). > > And that's _if_ amanda passes that on the dump invocation. > I haven't tried it either or looked at the code yet. > > But one limitation (with solaris' ufsdump and linux's dump) is that > you can't do incrementals using that method. Level 0 only. I don't > know if amanda adds support on top of that to kludge in incremental > support - I doubt it, but I'm someone will speak up if you can. > In the original query regarding ZFS the question was about file systems. I don't know if dump/ufsdump would regard a relative pathname that is a mount point as a file system. If it did, then incrementals and fulls could both be done. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 12027 Creekbend Drive (703) 787-0884 Reston, VA 20194 (703) 787-0922 (fax)
Re: Amanda and ZFS
>> ... >> The gtar devs finally accepted something to help with this problem: >> --no-check-device. >> ... Thanks, I hadn't caught the addition of that option. That also reminds me that the problem isn't the inode number, but the device number which was the problem. Pieter
Re: Amanda and ZFS
Jon LaBadie wrote at 13:57 -0400 on Apr 25, 2008: > Though I've not tried it, it should. > > I base that on the description of the command > > /usr/sbin/ufsdump [options] [arguments] files_to_dump > > and the belief that the include directive merely provides the args > corresponding to "files_to_dump". Ah. Okay. That's a solaris ufsdump feature... linux, too, maybe others. It won't work for the BSDs (filesystem only). And that's _if_ amanda passes that on the dump invocation. I haven't tried it either or looked at the code yet. But one limitation (with solaris' ufsdump and linux's dump) is that you can't do incrementals using that method. Level 0 only. I don't know if amanda adds support on top of that to kludge in incremental support - I doubt it, but I'm someone will speak up if you can.
Re: Amanda and ZFS
On Fri, Apr 25, 2008 at 11:46:34AM -0600, John E Hein wrote: > Jon LaBadie wrote at 10:59 -0400 on Apr 25, 2008: > > Another way would be to use include directives. For example, if the > > zfs pool was /pool and had file systems of a, b,c, and d, you could > > set up multiple DLEs that were rooted at /pool (different tag names) > > and had include directives of "include ./a ./c" and another with > > "include ./b ./d" While traversing each of the included starting > > points (directories), tar would never cross a file system boundary. > > Do those work when using 'dump' instead of 'tar'? Though I've not tried it, it should. I base that on the description of the command /usr/sbin/ufsdump [options] [arguments] files_to_dump and the belief that the include directive merely provides the args corresponding to "files_to_dump". jl -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 12027 Creekbend Drive (703) 787-0884 Reston, VA 20194 (703) 787-0922 (fax)
Re: Amanda and ZFS
Pieter Bowman wrote at 11:41 -0600 on Apr 25, 2008: > The final issue I found was that the inode numbers in the snapshots > change each time a new snapshot is created. This is a problem with > GNU tar's listed-incremental facility. To work around this I ended up > hacking GNU tar to make it ignore the inodes stored in the listed > incremental files. This was just a simple change, to have ZFS > filesystems treated the same as NFS. The patch was submitted to the > GNU tar developers, but was rejected. Here is the patch as applied to > GNU tar 1.16 (this patch also contains what I consider a fix for an > actual coding bug): The gtar devs finally accepted something to help with this problem: --no-check-device. http://article.gmane.org/gmane.comp.archivers.amanda.user/32804/match=nfs+tar
Re: Amanda and ZFS
I started using ZFS in a big way over a year ago on our main file server. Since there is no ufsdump replacement to use with ZFS, I elected to use GNU tar. I know this doesn't yet cover backing up things like ACLs, but we don't use them in our very heterogeneous environment. The main idea I had was to take a snapshot and point tar at the snapshot so it had a nice static, read-only copy of the filesystem to work from. I created a shell script to run as a cron job, just before amdump is run, which cleans up the previous snapshots and takes new snapshots of each of the pools (effectively): zfs destroy -r [EMAIL PROTECTED] zfs snapshot -r [EMAIL PROTECTED] Fortunately, amanda has a nice way to specify that the filesystem name is something like "/local", but the point to have tar start at is a different location. A disklist entry such as: foo.math.utah.edu /local /local/.zfs/snapshot/AMANDA user-tar The final issue I found was that the inode numbers in the snapshots change each time a new snapshot is created. This is a problem with GNU tar's listed-incremental facility. To work around this I ended up hacking GNU tar to make it ignore the inodes stored in the listed incremental files. This was just a simple change, to have ZFS filesystems treated the same as NFS. The patch was submitted to the GNU tar developers, but was rejected. Here is the patch as applied to GNU tar 1.16 (this patch also contains what I consider a fix for an actual coding bug): diff -r -c tar-1.16/src/incremen.c tar-1.16-local/src/incremen.c *** tar-1.16/src/incremen.c Fri Sep 8 10:42:18 2006 --- tar-1.16-local/src/incremen.c Fri Dec 8 14:53:37 2006 *** *** 71,77 #if HAVE_ST_FSTYPE_STRING static char const nfs_string[] = "nfs"; ! # define NFS_FILE_STAT(st) (strcmp ((st).st_fstype, nfs_string) == 0) #else # define ST_DEV_MSB(st) (~ (dev_t) 0 << (sizeof (st).st_dev * CHAR_BIT - 1)) # define NFS_FILE_STAT(st) (((st).st_dev & ST_DEV_MSB (st)) != 0) --- 71,77 #if HAVE_ST_FSTYPE_STRING static char const nfs_string[] = "nfs"; ! # define NFS_FILE_STAT(st) (strcmp ((st).st_fstype, nfs_string) == 0 || strcmp ((st).st_fstype, "zfs") == 0) #else # define ST_DEV_MSB(st) (~ (dev_t) 0 << (sizeof (st).st_dev * CHAR_BIT - 1)) # define NFS_FILE_STAT(st) (((st).st_dev & ST_DEV_MSB (st)) != 0) *** *** 247,253 directories, consider all NFS devices as equal, relying on the i-node to establish differences. */ ! if (! (((DIR_IS_NFS (directory) & nfs) || directory->device_number == stat_data->st_dev) && directory->inode_number == stat_data->st_ino)) { --- 247,253 directories, consider all NFS devices as equal, relying on the i-node to establish differences. */ ! if (! (((DIR_IS_NFS (directory) && nfs) || directory->device_number == stat_data->st_dev) && directory->inode_number == stat_data->st_ino)) { I hope this helps other people with using amanda and ZFS. I'm happy to clear up any unclear issues. Pieter
Re: Amanda and ZFS
Jon LaBadie wrote at 10:59 -0400 on Apr 25, 2008: > Another way would be to use include directives. For example, if the > zfs pool was /pool and had file systems of a, b,c, and d, you could > set up multiple DLEs that were rooted at /pool (different tag names) > and had include directives of "include ./a ./c" and another with > "include ./b ./d" While traversing each of the included starting > points (directories), tar would never cross a file system boundary. Do those work when using 'dump' instead of 'tar'?
RE: Amanda and ZFS
neat > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Jon LaBadie > Sent: 25 April 2008 16:00 > To: amanda-users@amanda.org > Subject: Re: Amanda and ZFS > > On Fri, Apr 25, 2008 at 02:32:27PM +0100, Anthony Worrall wrote: > > Hi > > > > unfortunately zfsdump, or "zfs send" as it is now, does not relate to > > ufsdump in any way :-( > > > > > [ big snip ] > > > > One of the properties of zfs is that in encourages the use of a > > filesystem for a logical set of files, i.e. user home directory, > > software package etc. > > This means that every time you create a new filesystem you need to > > create a new DLE for amanda. In fact creating the amanda DLE takes > > longer than creating the zfs filesystem. > > > > You can not just use tar to dump multiple zfs filestems because amamda > > tells tar not to cross filesystem boundaries. > > > > You could probably write a wrapper to tar to remove --one-file-system > > option to get around this limitation. > > Another way would be to use include directives. For example, if the > zfs pool was /pool and had file systems of a, b,c, and d, you could > set up multiple DLEs that were rooted at /pool (different tag names) > and had include directives of "include ./a ./c" and another with > "include ./b ./d" While traversing each of the included starting > points (directories), tar would never cross a file system boundary. > > -- > Jon H. LaBadie [EMAIL PROTECTED] > JG Computing > 12027 Creekbend Drive(703) 787-0884 > Reston, VA 20194(703) 787-0922 (fax)
RE: Amanda and ZFS
Anthony Worrall wrote at 14:32 +0100 on Apr 25, 2008: > unfortunately zfsdump, or "zfs send" as it is now, does not relate to > ufsdump in any way :-( Sorry to hijack this thread, but... Can Solaris and/or ZFS snapshots support partial filesystem dumps (and restores)? If not, how do people using dump for backups support large filesystems (that may be bigger than a tape)? Are split dumps and dump/restore or tar with excludes the only way in amanda right now?
Re: Amanda and ZFS
Anthony Worrall wrote: Hi unfortunately zfsdump, or "zfs send" as it is now, does not relate to ufsdump in any way :-( hmm. I guess I was being a bit naive. I had assumed zfs development was more mature. After reading the comments on this thread, I went searching for references to zfsdump (which doesn't exist, but nevertheless is a good search term for discussions of the missing capability). There are a variety of discussions on Sun's web site and others regarding difficulties with figuring out how to backup zfs, most particularly with respect to disaster recovery, where file system structure and information have been lost. This gives me a bit more insight into comments from a Sun engineer we met with a couple of weeks ago (ok, he was an engineer specializing in Sun storage systems who works for the vendor who has the Sun contract for our state). Anyway, when I asked him if ZFS was ready for prime time, he hedged. I asked why people weren't adopting it more. He said that it hadn't really panned out, and that UFS had developed more during the time of ZFS development. So, most people were sticking with UFS. Of particular note was that ZFS isn't really supported for your boot drive. Based on our discussions with this engineer, the new servers and storage systems we are getting will be set up entirely without ZFS. However, given my earlier naive assumptions, I'm not going to assume that this is the complete story. Just enough to get my skepticism and sysadmin conservatism into full gear. ;-) --- Chris Hoogendyk - O__ Systems Administrator c/ /'_ --- Biology Department (*) \(*) -- 140 Morrill Science Center ~~ - University of Massachusetts, Amherst <[EMAIL PROTECTED]> ---
Re: Amanda and ZFS
On Fri, Apr 25, 2008 at 02:32:27PM +0100, Anthony Worrall wrote: > Hi > > unfortunately zfsdump, or "zfs send" as it is now, does not relate to > ufsdump in any way :-( > > [ big snip ] > > One of the properties of zfs is that in encourages the use of a > filesystem for a logical set of files, i.e. user home directory, > software package etc. > This means that every time you create a new filesystem you need to > create a new DLE for amanda. In fact creating the amanda DLE takes > longer than creating the zfs filesystem. > > You can not just use tar to dump multiple zfs filestems because amamda > tells tar not to cross filesystem boundaries. > > You could probably write a wrapper to tar to remove --one-file-system > option to get around this limitation. Another way would be to use include directives. For example, if the zfs pool was /pool and had file systems of a, b,c, and d, you could set up multiple DLEs that were rooted at /pool (different tag names) and had include directives of "include ./a ./c" and another with "include ./b ./d" While traversing each of the included starting points (directories), tar would never cross a file system boundary. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 12027 Creekbend Drive (703) 787-0884 Reston, VA 20194 (703) 787-0922 (fax)
RE: Amanda and ZFS
Hi unfortunately zfsdump, or "zfs send" as it is now, does not relate to ufsdump in any way :-( >From man zfs zfs send [-i snapshot1] snapshot2 Creates a stream representation of snapshot2, which is written to standard output. The output can be redirected to a file or to a different machine (for example, using ssh(1). By default, a full stream is generated. -i snapshot1Generate an incremental stream from snapshot1 to snapshot2. The incremental source snapshot1 can be specified as the last component of the snapshot name (for example, the part after the "@"), and it will be assumed to be from the same file system as snapshot2. The format of the stream is evolving. No backwards compati- bility is guaranteed. You may not be able to receive your streams on future versions of ZFS. I wrote a script to use this but I had a problem getting estimates for the incremental snapshots. I can not see how amrecover would not be able to restore from the snapshot as it does not know the format used. In fact there is no way that I know of to extract a file from the snapshot sort of recovering the whole snapshot. This is probably not too much of a big issue as the tape backup is only needed for disaster recover and snapshot can be used for file recovery. amrestore could be used with "zfs receive" to recover the snapshot. One of the properties of zfs is that in encourages the use of a filesystem for a logical set of files, i.e. user home directory, software package etc. This means that every time you create a new filesystem you need to create a new DLE for amanda. In fact creating the amanda DLE takes longer than creating the zfs filesystem. You can not just use tar to dump multiple zfs filestems because amamda tells tar not to cross filesystem boundaries. You could probably write a wrapper to tar to remove --one-file-system option to get around this limitation. Anthony Worrall > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Chris Hoogendyk > Sent: 25 April 2008 13:39 > To: Nick Smith > Cc: amanda-users@amanda.org > Subject: Re: Amanda and ZFS > > > > Nick Smith wrote: > > Dear Amanda Administrators. > > > > What dump configuration would you suggest for backing up a ZFS pool of > > about 300GB? Within the pool there several smaller 'filesystems'. > > > > Would you : > > > > 1. Use a script to implement ZFS snapshots and send these to the server > > as the DLE? > > 2. Use tar to backup the filesystems? We do not make much use of ACLs > > so tar's lack of ACL support shouldn't be an issue? > > 3. Something else? > > > > Question : If a use 2 can still use 'amrecover' which AFAIK would be the > >case if I went with 1?? > > > > The host is a Sun Solaris 10 X86 box is that pertinent. > > > I'm not on Solaris 10 yet, and haven't used ZFS, but . . . > > I understand that with ZFS you have zfsdump (just as with ufs I have > ufsdump). So you could usse zfsdump with snapshots. I'm guessing it > wouldn't be too hard to modify the wrapper I wrote for Solaris 9 that > uses ufsdump with snapshots and is documented here > http://wiki.zmanda.com/index.php/Backup_client#Chris_Hoogendyk.27s_Examp le > > If you have that pool logically broken up into a number of smaller > pieces that can be snapshotted and dumped, it will make it smoother for > Amanda's planner to distribute the load over the dump cycle. > > Shouldn't have any problems with amrecover. > > > > --- > > Chris Hoogendyk > > - > O__ Systems Administrator >c/ /'_ --- Biology Department > (*) \(*) -- 140 Morrill Science Center > ~~ - University of Massachusetts, Amherst > > <[EMAIL PROTECTED]> > > ---
Re: Amanda and ZFS
Nick Smith wrote: Dear Amanda Administrators. What dump configuration would you suggest for backing up a ZFS pool of about 300GB? Within the pool there several smaller 'filesystems'. Would you : 1. Use a script to implement ZFS snapshots and send these to the server as the DLE? 2. Use tar to backup the filesystems? We do not make much use of ACLs so tar's lack of ACL support shouldn't be an issue? 3. Something else? Question : If a use 2 can still use 'amrecover' which AFAIK would be the case if I went with 1?? The host is a Sun Solaris 10 X86 box is that pertinent. I'm not on Solaris 10 yet, and haven't used ZFS, but . . . I understand that with ZFS you have zfsdump (just as with ufs I have ufsdump). So you could usse zfsdump with snapshots. I'm guessing it wouldn't be too hard to modify the wrapper I wrote for Solaris 9 that uses ufsdump with snapshots and is documented here http://wiki.zmanda.com/index.php/Backup_client#Chris_Hoogendyk.27s_Example If you have that pool logically broken up into a number of smaller pieces that can be snapshotted and dumped, it will make it smoother for Amanda's planner to distribute the load over the dump cycle. Shouldn't have any problems with amrecover. --- Chris Hoogendyk - O__ Systems Administrator c/ /'_ --- Biology Department (*) \(*) -- 140 Morrill Science Center ~~ - University of Massachusetts, Amherst <[EMAIL PROTECTED]> ---
Re: amanda and zfs
Hi Anthony, Thanks for providing ufsdump wrapper to handle ZFS. When Application API (http://wiki.zmanda.com/index.php/Application_API) is implemented (hopefully in the next Amanda release after 2.5), creating application plugin for snapshot based filesystem such as ZFS will be easier. Issue 1 will be handled by Application API. Paddy On 3/8/06, Anthony Worrall <[EMAIL PROTECTED]> wrote: > Hi > > I have playing about with Sun's new filesystem ZFS. > > One of the things I wanted to do was make sure I could get amanda to > backup zfs. > The way the backup utility works with zfs is based on snapshots. You can > either > do a full bakup of a filesystem or the difference between two snapshots. > The restore process is an all or nothing recovery of the snapshot. There > is no > way to recover a single file from a backup or to index the snapshot. > > I have hacked a script to replace ufsdump which will manage the > snapshots and > appropriately respond to amanda's sendsize and sendbackup requests which > is included below. > It requires that the amanda user has a role that can run the zfs > command. Also the > zfs DLE's should have indexing turned off. > > Here are some observations about zfs and amanda. ZFS encourages the use > of more > smaller filesystems at the home directory or even software package level > as it is easy > to grow and manage filesystems. This may have an impact on amanda in a > couple of ways. > > 1. Amanda seems to be more likely to do a full backup of the filesystem > since it is >small. However with many small filesystems the total amount of data > backed up may >end up being larger. Currently I have only a handfull of filestesm > with a few megabytes >each and amanda has only request fullbackups > > 2. With many filesystems managing the DLE's becomes more complex. One > idea maybe to >haves the DLE's for a client stored on the client. Amanda would then > need to get >the DLEs during the estimate phase or when doing a check of the > client. This >would also be useful in the case where the management of the client > is separated >from the backup management. > > I guess some of this issues may be addressed in 2.5 > > Cheers > > Anthony Worrall > > #!/bin/pfksh > #need to use pfksh so that zfs can be run > > ZFS=/usr/sbin/zfs > > #Get the last argument > for FS in $@; > do > echo $FS > /dev/null > done > > #Check if the filesystem is zfs or ufs > res=`$ZFS list | /usr/xpg4/bin/egrep "${FS}$"` > if [ $? -eq 0 ]; then > DEV=`echo $res | awk '{ print $1}'` > ESTIMATE=0 > LEVEL="unknown" > UPDATE=0 > > case $1 in > *0*) LEVEL=0;; > *1*) LEVEL=1;; > *2*) LEVEL=2;; > *3*) LEVEL=3;; > *4*) LEVEL=4;; > *5*) LEVEL=5;; > *6*) LEVEL=6;; > *7*) LEVEL=7;; > *8*) LEVEL=8;; > *9*) LEVEL=9;; > *) echo level NOT specfied; exit -1;; > esac > > case $1 in > *S*) ESTIMATE=1;; > esac > > case $1 in > *u*) UPDATE=1;; > esac > > $ZFS list -H -t snapshot | /usr/xpg4/bin/grep -q [EMAIL PROTECTED] > if [ $? -eq 0 ]; then > $ZFS destroy [EMAIL PROTECTED] > fi > $ZFS snapshot [EMAIL PROTECTED] > > # make sure all the snapshots up to $LEVEL exist > n=1 > while [ $n -le $LEVEL ]; > do > $ZFS list -H -t snapshot | /usr/xpg4/bin/grep -q [EMAIL PROTECTED] > if [ $? -ne 0 ]; then > LEVEL=$(( $n - 1 )) > break > fi > n=$(($n+1)) > done > > full=`$ZFS list -H -o refer [EMAIL PROTECTED] > #convert returned size into kilobytes > case $full in > *K) full=`echo $full | sed -e 's/K//'`;; > *M) full=`echo $full | sed -e 's/M//'`; full=$(( $full * 1024 ));; > *G) full=`echo $full | sed -e 's/G//'`; full=$(( $full * 1024 * > 1024));; > esac > if [ $LEVEL -gt 0 ]; then > incr=`$ZFS list -H -o refer [EMAIL PROTECTED] > case $full in > *K) full=`echo $full | sed -e 's/K//'`;; > *M) full=`echo $full | sed -e 's/M//'`; full=$(( $full * 1024 ));; > *G) full=`echo $full | sed -e 's/G//'`; full=$(( $full * 1024 * > 1024));; > esac > size=$(( $full - $incr )) > else > size=$full > fi > size=$(( $size + 16 )) > if [ $ESTIMATE == 1 ]; then > #echo "doing Estimate $DEV at level $LEVEL" >&2 > size=$(( $size * 1024 )) > echo $size > $ZFS destroy [EMAIL PROTECTED] > else > #echo "Dumping $DEV at level $LEVEL" >&2 > if [ $LEVEL -eq 0 ]; then > $ZFS backup [EMAIL PROTECTED] > else > $ZFS backup -i [EMAIL PROTECTED] [EMAIL PROTECTED] > fi > block=$(( $size * 2 )) > MB=$(( $size / 1024 )) > echo "DUMP: $block blocks (${MB}MB)" >&2 > if [ $UPDATE -eq 1 ]; then > for snap in `$ZFS list -H -t snapshot | awk '{print $1}' | egrep > ${DEV}@"[1-9]"`; do > n=`echo $snap | cut -f2 [EMAIL PROTECTED] > if [ $n -gt $LEVEL ]; then >$ZFS destroy $snap > fi > done > n=$(( $LEVEL + 1 )) > $ZFS rename [EMAIL PROTECTED] [EMAIL PROTE