Skip to main content

EXT4 partition backup (Linux).

Thread needs solution
Regular Poster
Posts: 20
Comments: 101

I'm booting off Acronis True Image 2018 (USB stick) with Linux recovery.

Running the backup Wizard if I select an EXT4 partition I get:

"Some partitions contain errors and can only be imaged sector by sector".. etc.

Are you kidding me - Still no support for EXT4! (Unless I do sector by sector I guess).

How does Acronis 2019 do here? I don't think there is any improvement is there?

I can't believe it states here that 2014 and 2015 were compatible - should have stuck with these products - why did I bother upgrading?
https://kb.acronis.com/content/6045

 

Acronis 2018 stated it backs up your mobile phone, but it turns out it doesn't do all of it.

Seriously guys! Stop giving us flashy stuff and give us just the basic we would expect. This is hardly exotic stuff.

0 Users found this helpful
Legend
Posts: 110
Comments: 28989

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.

Beginner
Posts: 0
Comments: 4

I had a similar issue. I have two laptops, which both are dual-boot including Windows 10 and (a) Ubuntu / (b) Debian. While Acronis True Image Home 2012 was perfectly able to produce an image backup of my laptop with Windows 10 and Ubuntu (without sector-by-sector!), this was not the case with my similar other notebook containing Windows 10 and Debian. First I thought this was due to Debian. I therefore replaced Debian with Ubuntu. But still I received the message, that the ext4 partition would contain errors. But according to fsck this was not the case. Fiddling around with this for hours I finally found out that not every ext4 partition is the same: When making an ext4 file system, there are certain options to be defined. It seems that depending on these options Acronis will or will not be able to make an image backup of ext4 without the need for its sector-by-sector procedure. I found that the following command works when making an ext4 file system:

sudo mkfs.ext4 -b 4096 -E lazy_itable_init=0 -I 256 -i 16384 -O filetype,large_file,sparse_super,uninit_bg,^64bit,^metadata_csum /dev/sdb6

Obviously you'll have to replace the "/dev/sdb6" part with the partition name you want to format.

Certain other options may also work but I have only tried the above and had success with it.

Beginner
Posts: 0
Comments: 6

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

Beginner
Posts: 0
Comments: 6

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

Legend
Posts: 110
Comments: 28989

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!).

Beginner
Posts: 0
Comments: 6

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

Legend
Posts: 110
Comments: 28989

Thanks Alex.

Beginner
Posts: 0
Comments: 6

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

Legend
Posts: 110
Comments: 28989

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

Forum Moderator
Posts: 246
Comments: 7080

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

Beginner
Posts: 0
Comments: 3

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

 

Beginner
Posts: 0
Comments: 6

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

Beginner
Posts: 0
Comments: 3

Alex,

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

 

Beginner
Posts: 0
Comments: 3

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.

Beginner
Posts: 0
Comments: 6

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

Legend
Posts: 110
Comments: 28989

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

Beginner
Posts: 0
Comments: 1

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

Legend
Posts: 110
Comments: 28989

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.

Legend
Posts: 110
Comments: 28989

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.

Attachment Size
529669-179379.zip 984.87 KB
Beginner
Posts: 0
Comments: 1

Alexandre Sidorenko 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