Advise for the (simpler) but best filesystem on iscsi

[Bruno Friedmann]

Hello Bareos users.

I've a case where the customer would like to have its backup media stored on an external qnap nas.
The nas is setup to export one volume by iscsi (the volume being a local raid5)

I can attach easily an openSUSE bareos small computer to that iscsi storage.
Now my question is what kind of filesystem would you use with which option ?

I know that xfs is good, but I'm concerned by what could happen on network errors.
Should I go to btrfs, I'm not familiar with, so what kind of advise you would give if using that one.
What about the copy-on-write etc?


I'm still less skilled to install a ZFS which I certainly should :-)

--

Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch

openSUSE Member & Board, fsfe fellowship
GPG KEY : D5C9B751C4653227
irc: tigerfoot

[Marco van Wieringen]

Bruno Friedmann <friedmann.bruno <at> gmail.com> writes:

>
> Hello Bareos users.
>
> I've a case where the customer would like to have its backup media
> stored on an external qnap nas.
> The nas is setup to export one volume by iscsi (the volume being a
> local raid5)
>

Why use ISCSI that is about the worst overhead possible putting
a filesystem on top of that. QNAP is Linux so you could just compile
the SD to run natively on the server and forget about all the nasty
overhead. If you run a filesystem over ISCSI I think NFS will be just
as bad when the link get dropped. Unless you do ISCSI with failover etc
but I guess you have only one network path anyway.

> I can attach easily an openSUSE bareos small computer to that
> iscsi storage.
> Now my question is what kind of filesystem would you use with
> which option ?
>

One that is resilient to underlying problems, I have seen ext2/ext3 go
crazy and into readonly mode on cluster all the time so those for sure
not as remote filesystem.

> I know that xfs is good, but I'm concerned by what could
> happen on network errors.

Consistency of xfs and ext4 is about as much as what fsck can fix and
that is metadata only most of the time. e.g. your directory entries look
fine but you could have lost data all over the place.

> Should I go to btrfs, I'm not familiar with, so what kind of
> advise you would give if using that one.
> What about the copy-on-write etc?
>

At least it means that your filesystem will always be consistent
as to what consistency means that kind of is determined by the crash
it gets to handle.

> I'm still less skilled to install a ZFS which I certainly should

No idea how its on Linux but ZFS at least is proven. Then again running
it on ISCSI would not be my choice, it will determine corruptions just
as BTRFS but as to if its possible it depends on what setup you used
mirrored or raidzX is a requirement for it to fix anything otherwise it
will only say you have corrupted data and as the data is also check summed
its questionable what extra it brings.

--
Marco van Wieringen marco.van...@bareos.com
Bareos GmbH & Co. KG Phone: +49-221-63069389
http://www.bareos.com

Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
Komplementär: Bareos Verwaltungs-GmbH
Geschäftsführer: Stephan Dühr, M. Außendorf, J. Steffens,
P. Storz, M. v. Wieringen

[Bruno Friedmann]

On Sunday 08 March 2015 16.44:13 Marco van Wieringen wrote:
> Bruno Friedmann <friedmann.bruno <at> gmail.com> writes:
>
> >
> > Hello Bareos users.
> >
> > I've a case where the customer would like to have its backup media
> > stored on an external qnap nas.
> > The nas is setup to export one volume by iscsi (the volume being a
> > local raid5)
> >
> Why use ISCSI that is about the worst overhead possible putting
> a filesystem on top of that.

Well the inexpensive less intrusive to what was there I guess :-)

> QNAP is Linux so you could just compile
> the SD to run natively on the server and forget about all the nasty
> overhead. If you run a filesystem over ISCSI I think NFS will be just
> as bad when the link get dropped. Unless you do ISCSI with failover etc
> but I guess you have only one network path anyway.

QNAP is based on linux, but compiling and maintaining it for 1 is not worth the effort.
Plus if it would certainly with a synology one port to several community or even subscription
then I think we should probably think of it. But I would like to build it the way the rest of
bareos is build and tested with obs+travis.
An idea how to get that ?

>
> > I can attach easily an openSUSE bareos small computer to that
> > iscsi storage.
> > Now my question is what kind of filesystem would you use with
> > which option ?
> >
> One that is resilient to underlying problems, I have seen ext2/ext3 go
> crazy and into readonly mode on cluster all the time so those for sure
> not as remote filesystem.

you certainly want to know that ext4 is behaving the same :-)

>
> > I know that xfs is good, but I'm concerned by what could
> > happen on network errors.
> Consistency of xfs and ext4 is about as much as what fsck can fix and
> that is metadata only most of the time. e.g. your directory entries look
> fine but you could have lost data all over the place.

Yeap some file are there, but no more bareos/bacula volume ....
Thanks to crappy hardware.

> > Should I go to btrfs, I'm not familiar with, so what kind of
> > advise you would give if using that one.
> > What about the copy-on-write etc?
> >
> At least it means that your filesystem will always be consistent
> as to what consistency means that kind of is determined by the crash
> it gets to handle.
>
> > I'm still less skilled to install a ZFS which I certainly should
> No idea how its on Linux but ZFS at least is proven. Then again running
> it on ISCSI would not be my choice, it will determine corruptions just
> as BTRFS but as to if its possible it depends on what setup you used
> mirrored or raidzX is a requirement for it to fix anything otherwise it
> will only say you have corrupted data and as the data is also check summed
> its questionable what extra it brings.

Thanks for the tips, it just confirm the fact that if you want ZFS seriously
you have at least 2 nodes of storage with preferably 2 network path.

Well playing in soho market is always fun. They want the top for -less :-)
At least convinced to have a subscription ;-)

In fact most of the time, the problems are coming from bad hardware. and those are becoming
more and more are to find (firmware interaction, with nas os etc ... )

Sunday blues ... Thanks.

[Ashley]

Not to disagree too strongly with Marco but XFS is perfectly fine.

All you are doing with ISCSI is presenting the disk as a block device over the network. Imagine it like you are using a USB external drive only instead of using a USB bus you are using an ethernet switch.

ISCSI is perfect for attaching large block devices inside virtual machines (or physical) and that is what I was doing for two years prior to switching to Bareos. I am now using a 24 Slot LTO 6 auto-changer . With a 20 TB internal spool and dump partition for my Storage Daemon Server.)

I also have a 28TB ISCSI NAS being used as a data store to backup roughly 34 different servers. I get between 90 and 120MBs transfer speed.

If you are worried about performance stick it on its own interface or VLAN.

In my opinion you only run all of the same problems that you would with a regular external hard disk/raid unit. If it loses power or you pull out the USB/FibreC/FW cord without un-mountng it expect the same problems you would with USB.

I had the exact same concerns as you when i first started using ISCSI but i have found them all to be unfounded. It is a rock solid technology with great performance.

[Ashley]

PS Marco, There is great bottle of scotch coming your way when the VMWare plugin is in prod. :P

[Bruno Friedmann]

Thanks Ashley for sharing.
The best approach suggested by Marco for this kind of cheap infrastructure would be able to install bareos-sd directly on the nas
If line communication drop, the backup/restore fail, not the filesystem.