Paragon Drive Backup 9.0 Professional : problem with ext3

[xygor]

I am having trouble using the program with an ext3 filesystem. There are
two cases.

The first is with a Seagate 120 GB external disk drive with a USB
interface. The ext3 filesystem is inaccessible when running either the
WinPE version of the program or installed and running in WinXP. It is also
inaccessible on another computer from the WinPE version. It is not
installed on that PC so I didn't try that case. By inaccessible, I mean
that an archive cannot be created there and it is not possible to explore
the contents. Information about the partition is available in the disk
view. The filesystem is on the third partition which is 80 GB in size.

debugfs 1.41.3 (12-Oct-200
debugfs: show_super_stats
Filesystem volume name: xyzzy
Last mounted on: <not available>
Filesystem UUID: ed3b6eb6-06e2-4de9-bbb7-7376b13a61f2
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 4890624
Block count: 19535040
Reserved block count: 976752
Free blocks: 17667689
Free inodes: 4890612
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1019
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Filesystem created: Mon Sep 7 10:57:17 2009
Last mount time: Wed Sep 9 06:37:49 2009
Last write time: Wed Sep 9 06:41:00 2009
Mount count: 2
Maximum mount count: 27
Last checked: Mon Sep 7 15:06:36 2009
Check interval: 15552000 (6 months)
Next check after: Sat Mar 6 14:06:36 2010
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 6ddaf4e5-2cbd-438e-8f99-10071a2f6a38
Journal backup: inode blocks
Directories: 2


The second is on a Maxtor Onetouch4 1 TB external disk drive with a USB
interface. The ext3 partition is the only one and it uses the entire
drive space. This is only with the WinPE CD since the native OS is Linux
on that machine and I didn't try it on the other computer where the
program is installed. In this case, it is possible to create the backup
and explore the contents of the filesystem. The problem is that after
creating a backup of the machine's internal disk drive (about 60 GB over
six partitions), when booting back to Linux, a run of e2fsck reports that
the filesystem is clean, but forcing a check reveals errors. I did not
allow e2fsck to correct anything. The drive can be mounted and the
directories look ok. After I deleted the folder and its contents that
were created by Drive Backup, e2fsck reports that all is well.

debugfs: show_super_stats
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: dcb08548-5a4c-4c24-8a7b-0373c661d382
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal filetype needs_recovery sparse_super large_file
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 122109952
Block count: 244190000
Reserved block count: 12209500
Free blocks: 213857964
Free inodes: 122109914
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Filesystem created: Tue Sep 8 06:48:19 2009
Last mount time: Thu Sep 10 08:51:31 2009
Last write time: Thu Sep 10 08:51:31 2009
Mount count: 2
Maximum mount count: 34
Last checked: Wed Sep 9 06:00:50 2009
Check interval: 15552000 (6 months)
Next check after: Mon Mar 8 05:00:50 2010
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: 6aae2099-2533-495f-a38e-ed443fee9a02
Journal backup: inode blocks
Directories: 4

Any ideas on how to make Drive Backup 9.0 work on ext3?

[Paragon_Tommy]

Hello xygor,

To extract files or write files to an Ext3 file system with Drive Backup, the partition need not to be assigned a letter in Windows. Open Paragon Drive Backup 9.0, on the Disk Map, locate the partition (light yellow color) and make sure that there is no letter assigned (shown with an asterisk). If it does have a letter, right click, remove drive letter, and Apply.

Go to Tools > File Transfer Wizard, select the file you want to transfer into the Ext3 partition, or if you want to transfer out, change under "Source" to "Physical Partitions". If the destination is to an Ext3, in the following screen, select "save data to physical partitions"

To backup your image/archives to an Ext3 partition, select "Save data to physical partition" instead of "Save data to local/network drives"

I hope that helps.

-Tommy

[xygor]

Thank you for your reply, Paragon Tommy.

I was already doing as you suggested.

Here is some more information. The two scenarios are two different computers each with its own external disk drive.

In the scenario 1 setup, I reformatted the ext3 partition, but set the inode size to 128 (it was 256) as in the second scenario. Now I get the same result as the second scenario: I can make backups to and browse files and backup archives on the ext3 partition (as a physical partition, not a drive letter.) And like in the second scenario, fsck (run after booting Linux) indicates errors on the ext3 filesystem if a check is forced. Additionally, I get the same corruption if I do the backup from the installed Drive Backup program as with running the Advanced Recovery CD.

[xygor]

Apparently, CTMagazine found ext3 support broken also.
http://www.storagecraft.com/documents/CTMagazine.pdf

"1 The manufacturer offers this function but in our test we found that it did not work properly."

[Paragon_Tommy]

Hello xygor,

This could due to a limitation of the software. Can you submit a ticket in our systems and we will have our developers take a look into it. Thank you for your find. We hope to provide an explanation soon.

https://www.paragon-software.com/my-...endRequest.htm

Best Regards,
Tommy Phan

[xygor]

Ok, Tommy. I put in a ticket. Thank you.