-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 18.03.2010 14:28, Darren J Moffat wrote:
>
>
> On 18/03/2010 13:12, joerg.schill...@fokus.fraunhofer.de wrote:
>> Darren J Moffat<darren.mof...@oracle.com> wrote:
>>
>>> So exactly what makes it unsuitable for backup ?
>>>
>>> Is it the file format or the way the utility works ?
>>>
>>> If it is the format what is wrong with it ?
>>>
>>> If it is the utility what is needed to fix that ?
>>
>> This has been discussed many times in the past already.
>
>> If you archive the incremental "star send" data streams, you cannot
>> extract single files andit seems that this cannot be fixed without
>> introducing a different archive format.
>
> That assumes you are writing the 'zfs send' stream to a file or file
> like media. In many cases people using 'zfs send' for they backup
> strategy are they are writing it back out using 'zfs recv' into another
> pool. In those cases the files can even be restored over NFS/CIFS by
> using the .zfs/snapshot directory
For the archival of files, most utilities can be ... converted (probably
by including additional metadata) to store those. The problem arises
with zvols (which is where I'm considering zfs send for backup anyways).
Since these volumes already are an all-or-nothing scenario restorewise,
that argument against using send/receive is flawed from the getgo. ( to
restore individual files from a zvol exported as an iSCSI disk, the
backup software would have to go on the machine mounting the iSCSI disk,
not as a backup of the zvol itself), which basically means that apart
from the rollback of snapshots, the send/receive backupstream is only
likely to be used in a disaster-rebuild situation, where "restores all
of itself batch" is a feature, not a bug. In that scenario "restoring
everything" _IS_ a feature, not a bug.
As to your two questions above, I'll try to answer them from my limited
understanding of the issue.
The format: Isn't fault tolerant. In the least. One single bit wrong and
the entire stream is invalid. A FEC wrapper would fix this.
The utility: Can't handle streams being split (in case of streams being
larger that a single backup media).
Both of these usually gets fended off with the "was never meant as a
backup solution", "you're trying to use it as ufsdump which it isn't, on
purpose, ufsdump is oldfashioned" and similar arguments. Often
accompanied with creative suggestions such as using usb disks (Have you
ever tried getting several terabytes back and forth over USB?), and then
a helpful pointer to multiple-thousand-dollars worth of backup software,
as an excuse for why noone should be considering adding proper backup
features to zfs itself.
The last paragraph may sound like I'm taking a jab at specific people,
I'm not, really. But I've had my share of helpful people who have been
anything but helpful. Most of them taking care not to put their answers
on the lists, and quite a lot of them wanting to sell me services or
software (or rainwear such as macintoshes)
//Svein
- --
- --------+-------------------+-------------------------------
/"\ |Svein Skogen | sv...@d80.iso100.no
\ / |Solberg Østli 9 | PGP Key: 0xE5E76831
X |2020 Skedsmokorset | sv...@jernhuset.no
/ \ |Norway | PGP Key: 0xCE96CE13
| | sv...@stillbilde.net
ascii | | PGP Key: 0x58CD33B6
ribbon |System Admin | svein-listm...@stillbilde.net
Campaign|stillbilde.net | PGP Key: 0x22D494A4
+-------------------+-------------------------------
|msn messenger: | Mobile Phone: +47 907 03 575
|sv...@jernhuset.no | RIPE handle: SS16503-RIPE
- --------+-------------------+-------------------------------
If you really are in a hurry, mail me at
svein-mob...@stillbilde.net
This mailbox goes directly to my cellphone and is checked
even when I'm not in front of my computer.
- ------------------------------------------------------------
Picture Gallery:
https://gallery.stillbilde.net/v/svein/
- ------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuiWrwACgkQSBMQn1jNM7YvSACg9+Nh3REdxML6cnc0cWDP5cbP
co4AoKjmeYx3o4/iQhkW7/tgvfF1qPvN
=bNBT
-----END PGP SIGNATURE-----
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
