Selim,
Symantec does support ZFS as DSSU targets. I've also seen a SUN white
paper outlining the use of Thumper (Sun X4500) as a NB 6.5 media server,
where the best practice was to to configure multiple NB disk storage
units to use a distinct ZFS file system. In this case, all the ZFS file
systems serving as DSSUs utilized one zpool.
Hope this helps,
Sri
Selim Daoud wrote:
> unfortunately in this area, Symantec is not helping anyone. they even
> take their time to officially include zfs in their compatibility lists
> s-
>
> On Jan 16, 2008 1:26 PM, Paul Kraus <[EMAIL PROTECTED]> wrote:
>
>> Previous posts from various people:
>>
>>
>>>>> But ... NBU (at least version 6.0) attempts to estimate the
>>>>> size of the backup and make suer there is enough room on the DSSU to
>>>>> handle it. What happens when the free space reported by ZFS isn't
>>>>> really the free space ?
>>>>>
>>>> Regarding the question asked below namely "What happens when the free
>>>> space reported by ZFS isn't really the free space ?", is there an open
>>>> bug for this ?
>>>>
>> As others have said, not a ZFS bug, but a feature :-) Of
>> course, this behavior can be eliminated using ZFS reservations. My
>> comment was regarding the utility of using one ZFS pool to contain
>> MULTIPLE NBU Disk Stage Storage Units ... I just don't see the utility
>> there and I do see a downside.
>>
>>
>>> The NetBackup server scans a backup client system,
>>> It determines it will need 600gb of disk space on the disk store.
>>> It stats the zfs volume and sees there is 700 gb free (enough for the
>>> backup)
>>> Starts writing 600gb over multiple hours.
>>> in the meantime, 500gb is used elsewhere in the pool.
>>> NetBackup Fails differently that on vmfs+vxvm in this case?
>>>
>>> Isn't it NetBackups issue to make sure that it has reserved diskspace or at
>>> least checks for space _as_ it writes?
>>>
>> If a disk stage fills during a backup (and there is nothing to
>> prevent another application from filling it either) it first triggers
>> DSSU garbage collection to remove the oldest backup images that have
>> already been duplicated to other storage, if that does not succeed in
>> freeing up enough space (and I have seen it trigger GC multiple
>> times), then I have observed two different behaviors (probably related
>> to differing patch versions):
>>
>> 1. backup fails with a 129 error
>>
>> 2. backup is continued on tape media
>>
>> This latter 'solution' ends up creating a unusable backup
>> image as NBU now doesn't know how to deal with an image that crosses
>> storage units, but that is very off topic for this list :-)
>>
>> My question was more toward how NBU will deal with the apparent
>> SIZE of the DSSU on ZFS changing on a frequent basis.
>>
>> --
>> {--------1---------2---------3---------4---------5---------6---------7---------}
>> Paul Kraus
>> -> Sound Designer, Noel Coward's Hay Fever
>> @ Albany Civic Theatre, Feb./Mar. 2008
>> -> Facilities Coordinator, Albacon 2008
>> _______________________________________________
>>
>> zfs-discuss mailing list
>> zfs-discuss@opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>>
>>
>
>
>
>
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
