On Thu, 2006-05-18 at 16:43 -0500, James Dickens wrote: > On 5/18/06, Gregory Shaw <[EMAIL PROTECTED]> wrote: > > On Thu, 2006-05-18 at 12:12 -0700, Eric Schrock wrote: > > > On Thu, May 18, 2006 at 11:42:58AM -0700, Charlie wrote: > > > > Sorry to revive such an old thread.. but I'm struggling here. > > > > > > > > I really want to use zfs. Fssnap, SVM, etc all have drawbacks. But I > > > > work for a University, where everyone has a quota. I'd literally have > > > > to create > 10K partitions. Is that really your intention? > > > > > > Yes. You'd group them all under a single filesystem in the hierarchy, > > > allowing you to manage NFS share options, compression, and more from a > > > single control point. > > > > > > > I'd agree except for backups. If the pools are going to grow beyond a > > reasonable-to-backup and reasonable-to-restore threshold (measured by > > the backup window), it would be practical to break it into smaller > > pools. > > > > After all, you'll probably have to restore a pool eventually. If that > > will take a week, your users won't be very happy with your solution. > > > > > > Of course, backups become a huge pain now. below, that's cumbersome > > > > for both backups and (especially) restores. > > > > > > Using traditional tools or ZFS send/receive? We are working on RFEs for > > > recursive snapshots, send, and recv, as well as preserving DSL > > > properties as part of a 'send', which should make backups of large > > > filesystem hierarchies much simpler. > > > > > > > Using EBS or NetBackup, can I get a single file back from tape only > > through the backup system? That's a big factor for production > > environments. Also, when users request a restore from tape from offsite > > backups, they'll usually specify a date range for when the file was > > 'good'. To accomplish that, you need to use the backup solution to find > > the requisite file. These 'fishing expeditions' (as I call them) can > > take a lot of time if direct access isn't available via the backup tool. > > ZFS basically eliminates the need to single file restores, because it > has snapshots, then the user can have almost instant access to old > copies of files. and is a lot quicker than even the fastest tape > library. Just make daily snapshots and the need to restore a single > file from tape is almost completely eliminated, you can still use > netbackup for disasters, but to get access to a single old file a > snapshot is much easier. > > You can also make it possible to have users initiate there own > snapshots when they feel the need arises. > > James Dickens > uadmin.blogspot.com >
The above would be fine for testing. However, on an active filesystem that is more than 50% full, you'll find that large amounts of space will be used by the snapshots. We currently use a pair of the Bluearc Titan fileserver appliances. They have very similar snapshot functionality. Currently, we can't maintain more than about 3 days of snapshots every 4 hours due to space constraints. For filesystems that don't move much, 1 snapshot per day for a year may be practical. I doubt it, as snapshots have to be managed, and maintaining 365 snapshots per filesystem (not pool) will be very difficult. [ stuff deleted ] _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
