Migrate Backup storage from BTRFS -->EXT4: How to?

Server
1

Hi there,
so I started somehow naive with a BTRFS backup storage volume. Meanwhile I feel a bit uncomfortable with my decision and would like to change it to the EXT4 file system. I know I will loose some real goodies which come with BTRFS with this change. However, I read the admin manual section 10.8 Migrate non-btrfs backup storage and it seems that I cannot use the migration procedure described there because I have a BTRFS storage as source.
Is there any advice how to migrate the backup storage from BTRFS --> EXT4 keeping all the client data and client backups?
Thanks in advance for some hints.

2

Hello

I dont think you can migrate in a direction or another , the storage format is too différent.
Ext4 would use symlinks and an external database to count links and whatnot.

Really btrfs should be better, what s your issue with it?

3

Hi orogor,
thanks for the feedback.
First, I do not question the very neat features of BTRFS which still attract me.

However, I feel unconformable whit BTRFS due to some readings and experiences I found on Internet forums etc… To narrow it down and to compare it EXT4:

  • BTRFS seems to be very sensitive to sudden power off or power failures of the NAS and hard to repair if even possible. A solution would be a UPS but I do not have one at home.

  • Precise values of remaining free space (sudo btrfs fi usage /path to BTRFS volume) of a BTRFS volume seems nearly impossible to acquire. It will give an estimation and not more. In parallel, BTRFS seems to be very sensitive to disk (nearly) full situation.

  • How to make a robust remote mirror/1:1 copy of a BTRFS disk, what is a proven method?

  • How to make an image of a BTRFS disk, what is a proven method?

  • BTFS needs care: Scheduling of scrubbing , balancing etc… Is this already done by UrBackup server?

Do you know more about these question which make me rather uncomfortable with BTRFS? For EXT4 there is usually more than one proven method/answer on an issue.
But, perhaps I only see ghosts with BTRFS …

4

There’s a few things, maybe btrfs is less resistant to failure in case of powerloss or full disk.
that’s important and needs to be double checked in recent versions to make sure it’s fixed.

The rest is basically not relevant:
Disk usage is known, it s more a philosophical argument about how you account for de-duped data,reflink for example.
Mirroring and imaging shouldn’t be an issue, you could use dd/lvm/btrfs build in mirror/btrfs send
The care you need to provide to btrfs has no equivalent in ext4. Balancing has no meaning in ext4. btrfs scrubbing would be ext4 fsck that you’d need to do offline in ext4.

That said, i am not 100% confident in btrfs myself, but i need to give it a serious go.

5

Thanks orogor for the quick reply and the insights.
I just found btrfsmaintenance: Scripts for btrfs maintenance tasks like periodic scrub, balance, trim or defrag on selected mountpoints or directories. So it seems that also others deal with some of the topics addressed here.

6

I also installed urbackup on btrfs at first, but it kept crashing too often.
Once I switched to ext4, it’s super steady and even resistant to power failures.

The only limitation is that unlimited incremental backups are no longer possible, but apart from that I’m satisfied with everything. Urbackup gives you the option to use soft or hard links for unchanged files in file backups, and use compressed VHD for image backups with only changed blocks from the previous backup, both features are somewhat a replacement for btrfs subvolumes and copy-on-write functionalities.

7

In my opinion at this point (kernel 4.19.x) if your btrfs is damaged after power loss, I’d look for the problem with other components first. For example using a RAID card that doesn’t sync properly, broken non-ECC RAM, early versions of linux 4.19 even had a block driver issue that caused corruption in rare cases (ok, so this one might be indirectly caused by btrfs, because btrfs forces you to use such recent Linux kernel versions).

Once btrfs metadata is damaged it is unlikely that it can be repaired, whereas ext4 can be repaired in most cases. Or you don’t even notice that there are problems with ext4 and it just silently removes files that UrBackup assumes are synced to disk during restarts.
Even after “repair” there might be critical files missing in backups, etc. so I wouldn’t trust repaired storage anyway…

8

Thanks for the replies and hints on my question.
After a longer back and forth in decision finding, I moved from BTRFS to EXT4. I did it in lack of other proven methods with this procedure:

  • Copying the urbackup/server_ident.key , and if present urbackup/server_ident.priv , urbackup/server_ident_ecdsa409k1.priv , urbackup/server_ident.pub and urbackup/server_ident_ecdsa409k1.pub to a safe place. (According to Urbackup FAQ)
  • Reinstall the Urbackup server from scratch
  • Exchange the new server keys with the ones I backuped before.
  • Starting new full backups of my clients to the new EXT4 backup storage