EXT4 partition backup (Linux).

Alex, I have an EXT4 Ubuntu partition on my laptop - dual-boot with Windows 10 and make backups of this using the ATI 2019 application from the GUI and see no mention of needing to use Sector-by-Sector mode in the backup log.

02/09/2018 14:02:36 :018  Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
02/09/2018 14:02:36 :020  Operation Ubuntu started manually.
02/09/2018 14:02:37 :069  Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
02/09/2018 14:02:37 :076  Operation: Backup
02/09/2018 14:02:37 :079  Priority changed to Low.
02/09/2018 14:02:38 :717  Create Backup Archive From: Ext4 (1-11); Linux Swap (1-12) To file: H:\Ubuntu\Ubuntu_full_b6_s1_v1.tib Compression: Normal
02/09/2018 14:02:38 :725  Pending operation 173 started: 'Creating partition image'.
02/09/2018 14:03:29 :336   Writing full version to file: Ubuntu_full_b18_s1_v1.tib
02/09/2018 14:07:47 :005  Pending operation 173 started: 'Creating partition image'.
02/09/2018 14:07:47 :866  Pending operation 173 started: 'Creating partition image'.
02/09/2018 14:07:48 :176  The following backups have been successfully created: H:\Ubuntu\Ubuntu_full_b18_s1_v1.tib
02/09/2018 14:07:50 :208  Operation has succeeded.

I wouldn't expect there be a big difference between the Windows ATI application and the standalone ATI application running from a USB stick.

I think that I have a reasonable theory of what exactly goes wrong. (I am a Linux developer and am aware of several problems with e2fsck and ext4). In particular, please read upstream discussion at https://lists.ubuntu.com/archives/ubuntu-server/2018-March/007671.html

The problem is that newer distributions create ext4 enabling 'metadata_csum' by default - but older versions of e2fsck do not understand it and think that FS is corrupted.

This makes the following theory look credible: Acronis ext4 code is based on an older version of ext4 and is not aware of this flag.

So I think that this is the only flag that needs to be reset to make EXT4 FS recognizable by Acronis, all other flags in previous message are irrelevant. I reset this flag only on my EXT4 (Ubuntu 18.04 LTS) and Acronis started seeing this partition properly. Exact instructions (assuming you use "/dev/sdv6"). Please note that you need to do this from recovery DVD or USB, FS should be unmounted

# e2fsck -f /dev/sdb6

# tune2fs -O '^metadata_csum'  /dev/sdb6

# e2fsck -f /dev/sdb6

There is no need to clear 64bit flag (and hence no need to use resize2fs).

I will submit a ticket to Acronis suggesting to update their code so that metadata_csum flag is processed properly

I think that I have a reasonable theory of what exactly goes wrong. (I am a Linux developer and am aware of several problems with e2fsck and ext4). In particular, please read upstream discussion at https://lists.ubuntu.com/archives/ubuntu-server/2018-March/007671.html

The problem is that newer distributions create ext4 enabling 'metadata_csum' by default - but older versions of e2fsck do not understand it and think that FS is corrupted.

This makes the following theory look credible: Acronis ext4 code is based on an older version of ext4 and is not aware of this flag.

So I think that this is the only flag that needs to be reset to make EXT4 FS recognizable by Acronis, all other flags in previous message are irrelevant. I reset this flag only on my EXT4 (Ubuntu 18.04 LTS) and Acronis started seeing this partition properly. Exact instructions (assuming you use "/dev/sdv6"). Please note that you need to do this from recovery DVD or USB, FS should be unmounted

# e2fsck -f /dev/sdb6

# tune2fs -O '^metadata_csum'  /dev/sdb6

# e2fsck -f /dev/sdb6

There is no need to clear 64bit flag (and hence no need to use resize2fs).

I will submit a ticket to Acronis suggesting to update their code so that metadata_csum flag is processed properly

Alexandre, thank you for your informed update and valuable contribution to this topic.  Please let us know the outcome of your support ticket with Acronis after you get a formal reply (other than the normal scripted responses!).

Hi Steve,

still have not heard from Acronis. In the meantime, found that to make everything work properly, you need to disable 64bit flag as well:

• clearing medata_csum makes Acronis see used space properly, but still "sector-by-sector"
• after clearing in addition 64bit, backup works as expected

Distributions started using 64bit as a default circa 2016-2017 (depending on your distribution). One of my hosts has been installed in 2014 and after that upgraded twice without recreating FS - and indeed, EXT4 on it have neither medata_csum not 64bit flags set. 

So to make things work you need to add to my previous recipe

# resize2fs -s /dev/hdb6

I have converted all my ext4 filesystems in this way they and are backuped properly (checked logfiles)

Alex

Thanks Alex.

FYI: I have exchanged  two emails with Acronis support, providing them exact instructions how to duplicate the problem and explaining that EXT4 periodically gets new features , so that they need to periodically re-test. 

Their manager told me that all my comments have been shared with their development team. Now we can only wait and hope that they will fix it in one of maintenance releases.

Alex

Alex, thank you once again for taking your time to do this - let's hope the waiting isn't too long!

Alex, thank you so much for sharing the results of your investigation! I've passed them to the RnD.

Alex,

Do you need to set the flags (metadata_csum and 64-bit) back to original setting after you do the ATI backup for the system to work properly? Seems like you might lose functionality if you leave the flags set as you suggest.

Thanks

nskipper1@gmail.com wrote:

Alex,

Do you need to set the flags (metadata_csum and 64-bit) back to original setting after you do the ATI backup for the system to work properly? Seems like you might lose functionality if you leave the flags set as you suggest.

Thanks

***

No need to change anything. '64bit' flag lets you create larger filesystems, but even without it you can create 16TB FS. (Depends on block size, sed https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout for exact numbers).

'metadata_csum' lets ext4 detect data corruption in some cases, see https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums for details.

 

To summarize: if you do not need FS larger than 16TB and your disk is working reliably. disabling these two flags does not prevent system from working properly. 

Alex

Alex,

Thanks. That is exactly what I need to know. Confirms what I determined from other sources.

Followed Alexandre's suggestions to disable "64bit" and "metadata_csum" on ext4 partition containing Xubuntu 19.04 64-bit OS while booted to Xubuntu 19.04 Live DVD. 

Booted to Acronis True Image 2016 Free (Seagate DiscWizard) Rescue CD (Linux-based).

Backed up the above ext4 partition. No "Some partitions contain errors and can only be imaged sector by sector" message. No sector by sector backup. Perfect!

Booted to above Xubuntu ext4 partition and everything works as before.

Thanks again Alexandre.

Hi all,

I have upgraded to True Image 2020 and can confirm that EXT4 is now processed properly, without manual tuning:

1. I have created a new EXT4 partition with default options on Ubuntu 18.04 LTS, copied about 2Gb of data to it

2. Verified that it has 'metadata_csum'  and '64bit' flags set - these were the flags that triggered the problem for TI 2019

3. Created a new backup for this partition only.

4. Looked at the logfile - it is clean, no problems reported

FYI,

Alex

Alex, thanks for the update and for testing that this has been resolved with ATI 2020.

Problem is Not fixed with the linux created bootable media.

Still getting same error message and when I try to proceed even with sector by sector after clicking generate file name it comes up with another error that file name is incorrect. Like what, you (the program) created the file name not me after me clicking generate file name button.

Using it in windows 10 to backup my two Ubuntu ext4 partitions and linux swap partition so just hoping it can recognize linux ext4 partitions correctly while in windows 10.

Does anyone know if this type of Linux backup works while booted into windows 10?

True Image 2020

Glori, I have been able to backup my own Ubuntu ext4 partitions from Windows 10 using ATI 2019 and 2020 without any issues.

I have also used the ATI rescue media to do this on my dedicated Linux boxes, but for which I normally create the WinPE version of the rescue media, not the Linux media.

Tested my MVP WinPE ATI 2020 rescue media to backup my Samsung NC10 notebook running Xubuntu 18.04 LTS and captured screen images of the process.  See attached zip file.

Alexandre Sidorenko wrote:

nskipper1@gmail.com wrote:

Alex,

Do you need to set the flags (metadata_csum and 64-bit) back to original setting after you do the ATI backup for the system to work properly? Seems like you might lose functionality if you leave the flags set as you suggest.

Thanks

***

No need to change anything. '64bit' flag lets you create larger filesystems, but even without it you can create 16TB FS. (Depends on block size, sed https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout for exact numbers).

'metadata_csum' lets ext4 detect data corruption in some cases, see https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums for details.

 

To summarize: if you do not need FS larger than 16TB and your disk is working reliably. disabling these two flags does not prevent system from working properly. 

Alex

Thank you, Alex, for this great solution.  How does one reset the flags (metadata_csum and 64-bit) to their original values should one want to do so ? Indeed, how does one determine the original values of the flags ?

Many thanks