Re: Thinking of using ZFS/FBSD for a backup system

Hi,
I have been using FreeBSD/ZFS for our backup system for last few 
months.. We had 6TB external disks connected through Firewire to the 
Server. Last week all the backup data disappeared along with the pool 
and everything!!!..When I typed zpool status - it says no pool 
available..Build up to this incident has always been a firefighting 
situation for me. We use Rsync to sync all the servers to FreeBSD's ZFS 
pool everyday. Most of the time Rsync hung on the middle of the syncing 
process.  When this happen I have to restart the server to run the 
backup again and  mount the ZFS pool (it requires manual mounting most 
of the time!!). Sometimes it throws some error like -
GEOM: da0: corrupt or invalid GPT detected.
GEOM: da0: GPT rejected -- may not be recoverable.
GEOM: da1: corrupt or invalid GPT detected.
GEOM: da1: GPT rejected -- may not be recoverable
I don't know what caused the disappearance of the ZFS pool and if 
someone could explain how I can retrieve the data from the external 
disks, that would be really helpful?..

Many Thanks

Aslam Mohamed

Network Support Analyst


Kris Kennaway wrote:
> Dmitry Morozovsky wrote:
>> On Wed, 9 Jul 2008, Kris Kennaway wrote:
>>
>> KK> > marck_at_wizzle:/usr/ports> grep -Ril zfs Tools/
>> KK> > Tools/portbuild/scripts/claim-chroot
>> KK> > Tools/portbuild/scripts/clean-chroot
>> KK> > Tools/portbuild/scripts/cleanup-chroots
>> KK> > KK> > ;-)
>> KK> > KK> > Any pitfalls while using this? Thanks!
>> KK> KK> It's still settling on pointyhat, but you could check it out 
>> there if you
>> KK> like.  The most annoying thing is actually a limitation of the 
>> FreeBSD NFS
>> KK> server, since it returns errors to clients while it is reloading 
>> the export
>> KK> list.
>>
>> Argh. And, which process is reporting an error? nfsd or some of 
>> kthreads? In the former case, is it possible to create new 
>> master-slave process tree, rebinding and signalling old tree to exit 
>> when all requests are finished?
>>
>> The same approach is used by www/nginx to both seamless configuration 
>> change and also binary file upgrade.
>>
>> CC:ing -current_at_ to ensure the theme have a bit broader audience.
>
> The problem is that updating the NFS export list is not atomic. 
> Instead, it is deleted and reloaded.  This means that client I/O 
> requests that are received during the window do not correspond to a 
> valid export, and the server dutifully returns an error to the client.
>
> This is made worse by the practice of mount(8) (and zfs(8)) of 
> SIGHUP'ing mountd every time a new filesystem is mounted (even if it's 
> not exported).  I have disabled this locally, but it doesn't help when 
> I really do want to export a newly mounted filesystem but I have 
> clients doing I/O.
>
> A few years ago there was a patch from Andrey Simonenko 
> <simon_at_comsys.ntu-kpi.kiev.ua> that implemented atomically reloading 
> the mount list, although it was unfortunately a mixture of these and 
> other changes including some that might be seen as gratuitous (e.g. it 
> depended on a new library).  Unfortunately the patch no longer seems 
> to be available on the original website and my attempt to contact 
> Andrey has failed.
>
> Kris
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to 
> "freebsd-current-unsubscribe_at_freebsd.org"