A little confused. Do "snapshots" (vs dump=image) have any correlation, non-unix?

I made a snapshot, it was "2.9G" but only actually
a few MB; then the dump was 503M. I've long
known about dumps, but the snapshot is
actually== ? in windows or "boot utility" terminology,
if an equivalent exists ??
..............
(Not an urgent question) afaik.

You can use ZFS snapshots as a poor-man's backup solution, in that you will have old versions of files accessible. However, using the same set of disks for "live" data and "backup" data is just asking for trouble in the long-run. This is what I do at home (3-disks in a raidz1 configuration, using daily ZFS snapshots to keep 30-60 days of "backups" around).

However, you can also use snapshots as a staging ground for creating off-system backups (copy the contents of the snapshot off to another server), and you can also create a backup server that uses snapshots to provide access to historical data (this is what we do at work; rsync data off remote server to ZFS, create snapshot, repeat daily).

It all depends on what you need, and what hardware you have available.

UFS snapshots are a little more tricky, but are still usable in roughly the same ways.

Thanks once again Freddie. So just to be clear, if the only thing I have is a snapshot, I'm probably out of luck if I have to rebuild the entire system, but if I just need some files from a prior date, I'm OK.

I haven't messed with zfs, but it may be worth it for use in my customer accounts. I will be building a NAS box for a client next week, and I am considering zfs as the file system. Is there anything I should or should not do in this case? We are going to have two RAID5 arrays, with 4 1.5TB drives in each. The second array will be used for backup of the first array. The production array will serve up NFS shares for our VM disk space.

Thanks once again Freddie. So just to be clear, if the only thing I have is a snapshot, I'm probably out of luck if I have to rebuild the entire system, but if I just need some files from a prior date, I'm OK.

Again, yes and no. Depends on how the snapshot is made, and what is stored in the snapshot.

For example, our backup server does a full system rsync of a remote server. Then takes a snapshot. The next night, it does another full system rysnc, and takes a snapshot. Any of those snapshots can be used to restore a system (boot off LiveCD, partition/format harddrives, rysnc system from backup server directory, install boot loader, reboot).

Thus, if your snapshots are of full, complete systems then they can be used to restore full, complete systems.

Quote:

I haven't messed with zfs, but it may be worth it for use in my customer accounts. I will be building a NAS box for a client next week, and I am considering zfs as the file system. Is there anything I should or should not do in this case? We are going to have two RAID5 arrays, with 4 1.5TB drives in each. The second array will be used for backup of the first array. The production array will serve up NFS shares for our VM disk space.

To get all the benefits of ZFS, you will need to disable the hardware RAID and let ZFS manage the disks directly. If the RAID controller has an option for "Single Disk" arrays, use that, as you then get all the functionality (cache, command re-ordering, offloading, etc) of the RAID controller, but with individual disks showing in the OS. If not, you'll have to use JBOD, which turned the RAID controller into a dumb SATA controller.

For your purposes, you have a couple of options:

create two separate storage pools, each with a single raidz1 vdev made up of the four disks

create a single storage, comprised of two raidz1 vdevs, each made up of four disks, and then create two separate ZFS filesystems (one as a backup of the other)

The former provides more separation between the two, but the second provides better I/O throughput and more storage space. You also have the option to add the raidz1 vdevs to the same pool to create either a striped (RAID0) pool, or a mirrored (RAID1) pool ("zpool add" vs "zpool attach"), depending on just how much redundancy you want.

Personally, I'd look into using two separate servers. One to host the live data, one to act as a backup. Then you can either use the "zfs send" command to keep them in sync by sending snapshots between them, or use rsync to keep them in sync.

On FreeBSD, native support for NFS sharing is available via the "sharenfs" property for individual filesystems (normal NFS configuration via /etc/rc.conf). You have to install Samba to share via SMB/CIFS. And you have to install an iSCSI target port if you want to export zvols via iSCSI.

On Solaris, NFS, SMB/CIFS, and iSCSI are done natively via the sharenfs, sharecifs, and shareiscsi properties.

For NAS and SAN purposes, ZFS is very nice. For storage on a single server (direct-attached) it's useful, depending on what you are doing. On a desktop, it's a bit overkill, but still has some perks.

OK, fantastic. I have it set up the second way with one storage pool since we'll have good backups and need the throughput. I have created two different file systems so we can use one for backup and one for production. Of course the client is being cheap and won't pay for two servers even though I agree with you that it is the way to go. I only have one question though. Since the file systems reside in the storage pool, there really is no way to know what vdev the data is in, it may even be striped across both of them as I understand it? Not that it makes any difference as if I am comprehending this correctly, the double RAID devices provide a measure of safety, more so than a single array would.

BTW, than you so much for the direction on this. I want to start using this configuration in all my client setups if it proves to be stable and reliable. Your help is always right on point as is most of the help on these forums.

AFAIK, you cannot determine what data is stored on what vdev, just that it's stored in that filesystem, in that storage pool. The data will be striped across all the vdevs in the pool. A single vdev or even a single disk is useless outside of the pool. You can basically treat the entire storage pool as "a single disk".

In essense, the storage pool is a RAID0 of all the vdevs.

You can, if you are really paranoid about data safety, created mirrored pools instead of striped pools. You create the pool and the first vdev as per normal. But, when you create the second (and subsequent) vdevs, you use:

zpool <poolname> attach <vdev type> <disk1> <disk2> <...>

That will create a RAID1 across all the vdevs. You lose disk space, but gain a lot more redundancy in the pool. (Probably not useful for most people/situations.)