Damon Atkins <damon_atk...@yahoo.com.au> wrote: > I vote for zfs needing a backup and restore command against a snapshot. > > backup command should output on stderr at least > Full_Filename SizeBytes Modification_Date_1970secSigned > so backup software can build indexes and stdout contains the data.
This is something that does not belong to stderr but to a separate stream that only allows to build a database. Stderr is used for error messages and warnings. > The advantage of zfs providing the command is that as ZFS upgrades or new > features are added backup vendors do not need to re-test their code. Could > also mean that when encryption comes a long a property on pool could indicate > if it is OK to decrypt the filenames only as part of a backup. > > restore would work the same way except you would pass a filename or a > directory to restore etc. And backup software would send back the stream to > zfs restore command. > > The other alternative is for zfs to provide a standard API for backups like > Oracle does for RMAN. You need to decide what you like to get...... >From what I've read so far, zfs send is a block level api and thus cannot be used for real backups. As a result of being block level oriented, the interpretation of the data is done zfs and thus every new feature could be copied without changing the format. If you like to have a backup that is able to retrieve arbitrary single files, you need a backup api at file level. If you have such an api, you need to enhance the backup tool in many cases where the file metadata is enhanced in the filesystem. We need to discuss to find the best archive formats for ZFS(NTFS) ACLs and for extended file attributes. I invite erybody to join star development at: https://lists.berlios.de/mailman/listinfo/star-developers and http://mail.opensolaris.org/mailman/listinfo/star-discuss Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de (uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
