[zfs-discuss] ZFS 'quot' command

2006-08-29 Thread William Fretts-Saxton
This was asked before, but was not responded to.  Is there a ZFS 
equivalent to the 'quot' command?

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


[zfs-discuss] new ZFS links page

2006-08-29 Thread Noel Dellofano

Hey everybody,
I'd like to announce the addition of a ZFS Links page on the  
Opensolaris ZFS community page.  If you have any links to articles  
that pertain to ZFS that you find useful or should be shared with the  
community as a whole, please let us know and we'll add it to the page.


http://www.opensolaris.org/os/community/zfs/links/

thanks,
Noel
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] new ZFS links page

2006-08-29 Thread James Dickens

On 8/29/06, Noel Dellofano [EMAIL PROTECTED] wrote:

Hey everybody,
I'd like to announce the addition of a ZFS Links page on the
Opensolaris ZFS community page.  If you have any links to articles
that pertain to ZFS that you find useful or should be shared with the
community as a whole, please let us know and we'll add it to the page.

http://www.opensolaris.org/os/community/zfs/links/


you are welcome to use any or all of the links included in this blog entry

http://uadmin.blogspot.com/2006/06/interested-in-zfs.html

James Dickens
uadmin.blogspot.com



thanks,
Noel
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


[zfs-discuss] ZFS + rsync, backup on steroids.

2006-08-29 Thread James Dickens

ZFS + rsync, backup on steroids.

I was thinking today about backing up filesystems, and came up with an
awesome idea. Use the power of rsync and ZFS together.

Start with a one or two large SATA/PATA drives if you use two and
don't need the space you can mirror other wise just use as in raid0,
enable compression unless your files are mostly precompressed, use
rsync as the backup tool, the first time you just copy the data over.
After you are done, take a snapshot, export the pool. And uninstall
the drives until next time. When next time rolls around have rsync
update the changed files, as it does block copies of changed data,
only a small part of the data has changed. After than is done, take a
snapshot.

Now thanks to ZFS you have complete access to incremental backups,
just look at the desired snapshots. For now rsync doesn't support
nfsv4 acls, but at least you have the data.

The best part of this solution is that its completely free, and uses
tools that you most likely are are already familiar with, and has
features that are only available in commercial apps.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZFS + rsync, backup on steroids.

2006-08-29 Thread Jason A. Hoffman

On Aug 29, 2006, at 12:17 PM, James Dickens wrote:

ZFS + rsync, backup on steroids.

I was thinking today about backing up filesystems, and came up with an
awesome idea. Use the power of rsync and ZFS together.

Start with a one or two large SATA/PATA drives if you use two and
don't need the space you can mirror other wise just use as in raid0,
enable compression unless your files are mostly precompressed, use
rsync as the backup tool, the first time you just copy the data over.
After you are done, take a snapshot, export the pool. And uninstall
the drives until next time. When next time rolls around have rsync
update the changed files, as it does block copies of changed data,
only a small part of the data has changed. After than is done, take a
snapshot.

Now thanks to ZFS you have complete access to incremental backups,
just look at the desired snapshots. For now rsync doesn't support
nfsv4 acls, but at least you have the data.


Yes I concur. This is how we do our backups, rsync + rolling over  
snapshots.


For example,

# ls -l /backups-4/pacific/.zfs/snapshot/
total 105
drwxr-xr-x  12 root sys   12 Feb 19  2006 20060620/
drwxr-xr-x  12 root sys   12 Feb 19  2006 20060621/
drwxr-xr-x  12 root sys   12 Feb 19  2006 20060622/
drwxr-xr-x  12 root sys   12 Feb 19  2006 20060623/
drwxr-xr-x  12 root sys   12 Feb 19  2006 20060624/
drwxr-xr-x  12 root sys   12 Feb 19  2006 20060625/
drwxr-xr-x  12 root sys   12 Feb 19  2006 20060626/
drwxr-xr-x  12 root sys   12 Feb 19  2006 20060627/
drwxr-xr-x  12 root sys   12 Feb 19  2006 20060628/
drwxr-xr-x  12 root sys   12 Feb 19  2006 20060629/

[emi:/] root# zpool list
NAMESIZEUSED   AVAILCAP  HEALTH ALTROOT
backups4   3.81T   3.39T434G88%  ONLINE -


Regards, J


Jason A. Hoffman, PhD | Founder, CTO, Joyent Inc.
Applications = http://joyent.com/
Hosting  = http://textdrive.com/
Backups  = http://strongspace.com/
Weblog   = http://joyeur.com/
Email= [EMAIL PROTECTED] or [EMAIL PROTECTED]
Mobile   = (858)342-2179






___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZFS + rsync, backup on steroids.

2006-08-29 Thread Frank Cusack

On August 29, 2006 2:17:06 PM -0500 James Dickens [EMAIL PROTECTED] wrote:

ZFS + rsync, backup on steroids.


Seems to me 'zfs send | zfs recv' would be both faster and more efficient.

-frank
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZFS + rsync, backup on steroids.

2006-08-29 Thread Boyd Adamson

On 30/08/2006, at 5:17 AM, James Dickens wrote:

ZFS + rsync, backup on steroids.

I was thinking today about backing up filesystems, and came up with an
awesome idea. Use the power of rsync and ZFS together.

Start with a one or two large SATA/PATA drives if you use two and
don't need the space you can mirror other wise just use as in raid0,
enable compression unless your files are mostly precompressed, use
rsync as the backup tool, the first time you just copy the data over.
After you are done, take a snapshot, export the pool. And uninstall
the drives until next time. When next time rolls around have rsync
update the changed files, as it does block copies of changed data,
only a small part of the data has changed. After than is done, take a
snapshot.

Now thanks to ZFS you have complete access to incremental backups,
just look at the desired snapshots. For now rsync doesn't support
nfsv4 acls, but at least you have the data.

The best part of this solution is that its completely free, and uses
tools that you most likely are are already familiar with, and has
features that are only available in commercial apps.


I've been doing this for a while (although I don't remove the disks,  
just keep them on the other side of the network).


I got the idea from the tool I was using before (http:// 
www.rsnapshot.org/) which uses hard links to reduce the space usage  
at the destination.


You might like to consider the --inplace option to rsync which should  
reduce the space usage for files which change in place, since rsync  
will just do the changed blocks, rather than making a copy then  
applying the changes. The latter will result in all unchanged  blocks  
in the file being duplicated (in snapshots) on ZFS.


Boyd

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] ZFS + rsync, backup on steroids.

2006-08-29 Thread Mike Gerdts

On 8/29/06, James Dickens [EMAIL PROTECTED] wrote:

ZFS + rsync, backup on steroids.



If you combine this with a de-duplication algorithm you could get
really space-efficient backups.

Suppose you have 100 (or 1000, or 1) machines to back up that are
the same 3 GB OS image + mixed bag of apps + various prod/non-prod
copies of databases + per-machine customization.   Wouldn't it be nice
if the backup server would store figure out that each machine is
mostly the same and store one copy.  Perhaps having a mechanism that
it would store a per-block checksum in a database, then look for
matches by checksum (aka hash) each time a block is written.  Hash
collissions should be verified with full block compare.

Then you could create your restore procedure as a CGI or similar web
magic that generates a flar based upon the URL+args provided.  That
URL can then be used in a jumpstart profile as archive_location
http://backupserver.mycompany.com/flar/...;.  A finish script would be
responsible for using rsync or simlar to copy the sysidcfg-related
files that jumpstart/flar refuses to preserve.

FWIW, de-duplication seems to be a hot topic in VTLs (Virtual Tape
Libraries).  This would be an awesome feature to have in ZFS, even if
the de-duplication happens as a later pass similar to zfs scrub.

Mike

--
Mike Gerdts
http://mgerdts.blogspot.com/
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss