When will BTRFS be supported?

[kpl]

Hello guys,

will BTRFS be supported by any chance? Actually this file system is the future and will replace soon or later ext4 and so on?
For me or my company its pretty essential because SAP is recommending SLES 12 with BTRFS for their system/db environment to run with.

Greetings

kpl

[PTide]

Hi,

It'd be great if you shared the article/release notes where SAP actually recommends BTRFS so I could take a look, because I've never heard of such recommendation before. If there's a huge demand, we can discuss the feature request.

Thanks

[HannesK]

I just got the request from a customer (but without SAP) earlier this week. They use RedHat / CentOS with btrfs.

[Anja]

Hello,
we use SLES 12SP2 on physical server and consider to use Veeam Agent for Linux for system backup. Unfortunately BTRFS isn't supported by Agent for Linux, is it planned to be supported in future releases?
Anja

[PTide]

Hi Anja,

We don't have plans to support BTRFS so far.

Thank you

[jjschopp]

Hello guys,

I would like to also see BTRFS to be supported as well.

[chris400]

With SUSE Linux Enterprise 12, Btrfs is the default file system for the operating system

https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/

[danjohnson]

Another vote for BTRFS please - without this support this product is no use to us

[hgrams]

Almost one year later. BTRFS is now standard on SuSE and just a matter of time when other distributions use BTRFS. Currently you still have to do pull-ups to perform single file restores from such a Linux environment. This is one of the reasons why some of our customers do not want to use Veeam. Very bad

Now, is there more positive information for the support of BTRFS?

Thanks Harald

[PTide]

Hi,

We plan do to support BTRFS and are actively working on it, however I cannot say the exact version when this support is going to be delivered.

Thanks

[hgrams]

Thanks for the information. I hope the the planned release date is not so far away.

[mikeely]

I'm glad it's going to be (finally!) supported. I love how Veeam decided to support MurderFS(Reiser) but not btrfs on release. What decade is it again?

[PTide]

Hi,

Unlike BTRFS, ReiserFS support did not require significant changes to the kernel module, it was basically working out of the box. BTRFS, on the contrary, is a quite complex thing to support, it's not just another filesystem, but a complicated tool which features and capabilities extend far beyond what any other filesystem can provide (except for ZFS, maybe). Also, despite BTRFS being default SLES filesystem, it wasn't quite clear whether it is being widely used in reality. All these factors combined caused the delay of BTRFS support.

Thanks

[jan.schmidt]

Even if it already was requested, I will give one more vote for this request: we are currently implementing several SLES12SP3 installation, which I would like to backup. As in the meantime BtrFS is the default filesystem for SLES, there is one big question for me: is there any time frame for a release supporting BtrFS? I'm not finished with the installation and could switch to a supported filesystem, nevertheless this wouldn't be the best option for me.

[GuidoJ]

+1 for the request. We would really like to be able to backup our SLES12 installations with Veeam.

[Gostev]

I love how Veeam decided to support MurderFS(Reiser) but not btrfs on release. What decade is it again?

Unlike BTRFS, ReiserFS support did not require significant changes to the kernel module, it was basically working out of the box. BTRFS, on the contrary, is a quite complex thing to support, it's not just another filesystem, but a complicated tool which features and capabilities extend far beyond what any other filesystem can provide (except for ZFS, maybe).

I can confirm that BTRFS has been by far the most costly feature for Veeam Agent for Linux from R&D costs perspective. Now it's clearly how it was a VERY good choice to skip BTRFS initially!

[revog]

I can confirm that BTRFS has been by far the most costly feature for Veeam Agent for Linux from R&D costs perspective. Now it's clearly how it was a VERY good choice to skip BTRFS initially!

Sorry, but this does not matter from customer side.
SLES12 is fully supported by Veeam and on its compatibility list. Further on Suse defined Btrfs as default Filesystem ...

Anyway last post in this thread of commitment that Btrfs will be supported is from feburary ... any news on this?
And the crazy part: SLES15 has been announced and it is GA since June this year - and still no support for SLES12 and Btrfs ... crazy world, isn't it?

[PTide]

Sorry, but this does not matter from customer side.
SLES12 is fully supported by Veeam and on its compatibility list. Further on Suse defined Btrfs as default Filesystem ...

While I can somewhat agree with you I just want to make it clear that the fact that one particular distro has decided to make something to be default doesn't always matter from the development side either. Let me just present you some facts:

BTRFS was there since SLES 11, but the filesystem has been considered to be stable enough only for kernels starting from kernel version 3.16

SLES 11 SP4 runs on 3.0.101-81.1

SLES 12 got newer kernel (4.4.21-81) only in SP2.

Also regarding the "crazy part" - I don't quite understand what does the release of SLES 15 that happened three days ago has to do with support for BTRFS? Please elaborate.

Thank you

[revog]

While I can somewhat agree with you I just want to make it clear that the fact that one particular distro has decided to make something to be default doesn't always matter from the development side either.

Correct ... but what would be Veeam without any supported Filesystems/Distros?! Right, nothing than a piece of software which cannot be used. So Veeam should have an interest in the on-going market and be aware of trends coming from the IT sector and community! This definitely weakens your argument. Sorry to say that, but it is not Veeam who makes the rules/standards - Veeam has to adapt the very fast evolving market and provide some benefits and make its software - yeah let's say - mandatory.
If Veeam's development process is not that dynamic - then please do not proclaim a distro which does use Btrfs by default as fully supported! That's nothing than confusing.

Let me just present you some facts:

BTRFS was there since SLES 11, but the filesystem has been considered to be stable enough only for kernels starting from kernel version 3.16

SLES 11 SP4 runs on 3.0.101-81.1
SLES 12 got newer kernel (4.4.21-81) only in SP2.

Let me refer to the release notes of SUSE SLES 12 from April 2014! Yes you read correct - more than 4 years ago!
https://www.suse.com/releasenotes/x86_6 ... ate-316637

3.4.4 Default File System
With SUSE Linux Enterprise 12, the default file system in new installations was changed from Ext3 to Btrfs for the root system partition.

Do you wanna say 4 years (let's ignore the time in which Btrfs has been available linux kernel 2.6.29+) are too short for Veeam to get a feature implemented in its software?

This directly leads me to the "crazy part".

Also regarding the "crazy part" - I don't quite understand what does the release of SLES 15 that happened three days ago has to do with support for BTRFS? Please elaborate.

It has been more than 4 years ago (from today) since Btrfs has been defined as default root filesystem in SLES 12. A few days ago SUSE announced SLES 15. And yeah still no announcement by Veeam that Btrfs is fully supported. Wouldn't it be great to support a new distro from the beginning with its default filesystem? I think 4 years should be enough to put this Btrfs thing on the development schedule ....

Don't get me wrong - Veeam is doing a great job regarding the protection of virtual environments - but considering the Btrfs support, Veeam completely failed!

Regards Reto

[PTide]

<...>but what would be Veeam without any supported Filesystems/Distros?! Right, nothing than a piece of software which cannot be used.

I'd rather not have to deal with reductio ad absurdum on this forum, please.

Veeam supports the majority of popular and proven file systems that are available in most distros out of the box. That's why the argument about what Veeam would be is not entirely true. We, as a company, choose to support a particular set of technologies, based on users' feedback, our own findings and analysis, and we chose to do things properly. Sure, we could attempt to support literally everything and believe me, we really would love to do that, but given the amount of resources, current priorities we need to make a choice what should be supported in the first place, and what should be supported later.

If Veeam's development process is not that dynamic - then please do not proclaim a distro which does use Btrfs by default as fully supported! That's nothing than confusing.

If BTRFS was mandatory, or crucial, or essential, or, at least, obviously beneficial for SLES users, then I would agree. However it is only "by default" for some reason and it didn't seem to be very popular among our customers two years ago when Veeam Backup for Linux project has started.

Let me refer to the release notes of SUSE SLES 12 from April 2014! Yes you read correct - more than 4 years ago!
3.4.4 Default File System
With SUSE Linux Enterprise 12, the default file system in new installations was changed from Ext3 to Btrfs for the root system partition.
Do you wanna say 4 years (let's ignore the time in which Btrfs has been available linux kernel 2.6.29+) are too short for Veeam to get a feature implemented in its software?

What I want to say is

1. There was no Veeam Agent for Linux 4 years ago
2. There was no significant demand on BTRFS, while there was plenty of other stable and popular file systems to support, and that's exactly what we were busy with the whole time
3. Again, the file system was not quite stable back in days. As official BTRFS wiki directly says:

<...>Earlier versions may fail to list subvolumes when cleaner process is operating, and this could cause random failures during backup. That said, many fixes have gone in btrfs send/receive and it is recommended to use at least a 3.14, or 3.15 kernel to have later patches.<...>

SLES got its kernel climb higher than 3.12 only in SLES 12 SP2 (November 2016). There is no point supporting something that is changing its crucial internals on the fly.

Don't get me wrong - Veeam is doing a great job regarding the protection of virtual environments - but considering the Btrfs support, Veeam completely failed!

Can you please clarify what exactly Veeam failed? Don't get me wrong, I really want and support the idea of having BTRFS supported as soon as possible, that's why the priority of this feature is high. On the other hand, I may understand your frustration on not having his supported yet, but keep in mind that the file system's completness and production readiness are still questionable and the file system itself is not that common yet.

Thank you

[revog]

I'd rather not have to deal with reductio ad absurdum on this forum, please.

Me neither, but I wanted to make clear, that such a great software like Veeam's B&R / VAL need to consider the current market and do have to adapt to .

Veeam supports the majority of popular and proven file systems that are available in most distros out of the box. That's why the argument about what Veeam would be is not entirely true. We, as a company, choose to support a particular set of technologies, based on users' feedback, our own findings and analysis, and we chose to do things properly. Sure, we could attempt to support literally everything and believe me, we really would love to do that, but given the amount of resources, current priorities we need to make a choice what should be supported in the first place, and what should be supported later.

Yes I know, it's all about business and money. I can only repeat: this "later" in your last sentence would be okay regarding Btrfs - but not that many years as we are counting now.

1. There was no Veeam Agent for Linux 4 years ago

Doesn't make the things better - because same story applies to Veeam B&R .

3. Again, the file system was not quite stable back in days. As official BTRFS wiki directly says:

SLES got its kernel climb higher than 3.12 only in SLES 12 SP2 (November 2016). There is no point supporting something that is changing its crucial internals on the fly.

Okay, I agree - let's reduce the delay from 4 to 2 years - a bit better, but ....

Can you please clarify what exactly Veeam failed? Don't get me wrong, I really want and support the idea of having BTRFS supported as soon as possible, that's why the priority of this feature is high.

They failed regarding the still (after 2/4 years) missing Btrfs support. For me as a customer it's a digital thing - it is supported or not. Unfortunately the internal dev progress does not matter - I'd like to have a working Btrfs integration within - an obviously supported (based on marketing slides, requirements pages,...) operating system.

On the other hand, I may understand your frustration on not having his supported yet, but keep in mind that the file system's completness and production readiness are still questionable and the file system itself is not that common yet.

Correct, but cannot be that bad. Otherwise SUSE wouldn't have choosen this as default, right?
Anyway let's put this discussion aside and let's concentrate on Btrfs dev and integration .

----

The whole thing would be much less dramatic if a simple single-file backup and restore (not bare-metal desaster recovery) from a btrfs volume would be possible?
Our current backup solution is able to read and backup files on a Btrfs volume (with an installed agent aswell). Restore of a specific file/folder is possible aswell. But a disaster recovery (on bare metal) is not possible. How does this look in VAL? As far as I know, VAL completely declines the selection of a Btrfs volume beeing backuped. Do you understand what I mean?

Regards Reto

[PTide]

Doesn't make the things better - because same story applies to Veeam B&R .

No, it does not. Support for FLR from BTRFS has been added in v8 Patch 1 (2014-12-25):

Added support for file level recovery from BTRFS volumes (default OS file system in SUSE Linux Enterprise Server 12.0)

What story that applies to B&R were you referring to?

Otherwise SUSE wouldn't have choosen this as default, right?

We can only hope

The whole thing would be much less dramatic if a simple single-file backup and restore (not bare-metal desaster recovery) from a btrfs volume would be possible?

Yes, this time we might have over-engineered the product a little bit

As far as I know, VAL completely declines the selection of a Btrfs volume beeing backuped. Do you understand what I mean?

Yes, I understand. Support for both BTRFS BMR and simple single-file backup in VAL are coming soon.

Thanks

[KeiichiKun]

Hi all,
news about official support for BTRFS in next release of agent for linux (with 9.5u4)?
Roadmap?
Thanks

[nielsengelen]

Hi, it is on our roadmap to support it so stay tuned for a future release.

[revog]

Hi all,
news about official support for BTRFS in next release of agent for linux (with 9.5u4)?
Roadmap?
Thanks

I'm waiting for months now ...

[Gostev]

Fortunately for you, the remaining wait is not too long.

Unfortunately for me though, because supporting Btrfs ended up to be a colossal effort that took almost the same amount of dev and QC resources as all the previous VAL releases collectively. The complexity was sooo underestimated. In the hindsight, I would have postponed it further, and delivered a whole bunch of other major features instead... cause those collectively would increase a value of the product a few times more than this single feature. Oh well, what's done is done!

[KeiichiKun]

Absolutely amazing as always, thanks big boss!

[sdet00]

Pretty surprised to see that BTRFS isn't supported!

[Gomez]

I'm pleased to see full support for BTRFS is coming along.

In the current form, wouldn't VAL support simple file backups files that reside on BTRFS volumes?
In my case I was looking to backup up /etc /root which are on BTRFS, and store them on local rotating USB drives.
I would have thought that as native linux commands such as cp, dd, tar can copy from btrfs, than maybe VAL may do so as well.

My logic is that I am not seeking BMR, or volume or server image backups that may require some deep OS integration - just file backups but utilising the block level diff capabilities.

Similarly some of our servers have NSS volumes, and I wanted backup these files also.

Thanks

[PTide]

Hi Gordon,

That functionality is also coming soon.

Thanks!