On 19 mars 2010, at 17:11, Joerg Schilling wrote: >> I'm curious, why isn't a 'zfs send' stream that is stored on a tape yet >> the implication is that a tar archive stored on a tape is considered a >> backup ? > > You cannot get a single file out of the zfs send datastream.
zfs send is a block-level transaction with no filesystem dependencies - it could be transmitting a couple of blocks that represent a portion of a file, not necessarily an entire file. And since it can also be used to host a zvol with any filesystem format imaginable it doesn't want to know. Going back to star as an example - from the man page : "Star archives and extracts multiple files to and from a single file called a tarfile. A tarfile is usually a magnetic tape, but it can be any file. In all cases, appearance of a directory name refers to the files and (recursively) subdirectories of that directory." This process pulls files (repeat: files! not blocks) off of the top of a filesystem so it needs to be presented a filesystem with interpretable file objects (like almost all backup tools). ZFS confuses the issue by integrating volume management with filesystem management. zfs send is dealing with the volume and the blocks that represent the volume without any file-level dependence. It addresses an entirely different type of backup need, that is to be able to restore or mirror (especially mirror to another live storage system) an entire volume at a point in time. It does not replace the requirement for file-level backups which deal with a different level of granularity. Simply because the restore use-case is different. For example, on my Mac servers, I run two different backup strategies concurrently - one is bootable clone from which I can restart the computer immediately in the case of a drive failure. At the same time, I use the Time Machine backups for file level granularity that allows me to easily find a particular file at a particular moment. Before Time Machine, this role was fulfilled with Retrospect to a tape drive. However, a block-level dump to tape had little interest in the first use case since the objective is to minimize the RTO. For disaster recovery purposes any of these backup objects can be externalized. Offsite rotation of the disks used allow the management of the RPO. Remember that files exist in a filesystem context and need to be backed up in this context. Volumes exist in another context and can be replicated/backed up in this context. zfs send/recv = EMC MirrorView, NetApp Snap Mirror, EqualLogic Auto-replication, HP StorageWorks Continuous Access, DataCore AIM, etc. zfs send/recv ≠ star, Backup Exec, CommVault, ufsdump, bacula, zmanda, Retrospect, etc. Erik _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
