Why would Clonezilla suddenly go slow?

Thank you Laszlo.
I plan to , as soon as I move stuff off it.
I have a spare identical disk.

3 Likes

I did not understand that… thanks

Strange that it says PASSED

1 Like

I think these are the alarming values:

187 Reported_Uncorrect      0x0032   082   082   000    Old_age   Always       -       18
197 Current_Pending_Sector  0x0012   099   099   000    Old_age   Always       -       208
198 Offline_Uncorrectable   0x0010   099   099   000    Old_age   Offline      -       208

Passed / Failed “officially” is calculated from the VALUE /WORST/THRESHOLD columns.
These numbers are reported on logic of the manufacturer.
If the manufacturer sets up this so that the drive reports failing on the slightest problem, they would go out of business with all the warranty replacements.
So they better calculate a “safe” limit for errors for themselves. :wink:

My logic (and probably yours too) tells, that our data is much more important than the money we may need to spend on a replacement drive, hence we look at the RAW_VALUE in SMART, and decide ourselves, the drive passes or fails.

Your drive seems to fail, but that does not mean, it’s going to completely die today!
You have a very good chance to save all your precious data from it.

Edit:
After all you make your backups, because yon don’t even trust your absolutely healthy and flawless original drive. :wink:

Edit2:
Found about spare area I mentioned:

3 Likes

Don’t know if this might help, but found this.

https://sourceforge.net/p/clonezilla/discussion/Clonezilla_live/thread/2cd5a79ad5/

3 Likes

Rsyncing it now

root@trinity:/home/nevj# mkdir /mnt/from
root@trinity:/home/nevj# mkdir /mnt/to
root@trinity:/home/nevj# mount /dev/sda14 /mnt/from
root@trinity:/home/nevj# mount /dev/sdc11 /mnt/to
root@trinity:/home/nevj# rsync -aAXvH /mnt/from/ /mnt/to
sending incremental file list
./
Adelievm.qcow2
antix23runitvm.qcow2
..... and so on

Dont get confused, the faulty disk came up as sda in MX tonight.
I have 6 partitions to copy
Then I have to fix all the affected entries in /etc/fstab for every Linux hard installed.
and
If the partition moved is a Linux root partition, I have to remove /boot/grub/grub.cfg because it contains disk references that are wrong for the moved Linux.

It is interesting, I can run MX, and it seems unaffected by the failing disk, but Clonezilla was strangled… it did complete the backup last night … took 8 hours.

4 Likes

Thanks Howard,
There is quite a bit of discussion going on about the speed of Clonezilla… but mostly about its speed when writing backups. My issue was with time taken to probe for disks and partitions.
I cant find much on that, but I think my case was caused by a failing disk.
I cant be sure until I remove the failing disk.

3 Likes

@easyt50 , @kovacslt , @callpaul.eu , @pdecker , @Rosika

Thank you all for assistance with this issue.

Progress report:

  1. I have copied ( with rsync) from the failing HDD to my new SSD
    the following
  • qemu virtual disk images
  • two Linuxes - Devuan and Peppermint that I have not finished working on yet
  • one data directory.
    The new SSD now contains 12 partitions
    I adjusted the /etc/fstab files in Devuan and Peppermint, and removed grub.cfg in each
  1. I removed the power cable from the failing HDD, so that it was invisible to any OS, including Clonezilla

  2. I did an update-grub in the controlling Linux on the SSD ( MX) . It found all distros
    I Checked the bootability of MX, Void, Devuan, and Peppermint
    I checked ( in Void) that my VM’s all still worked ( because I moved the image file partition)

  3. I started the same Clonezilla as I used previously and setup a backup of the SSD disk to external USB disk.
    It took

  • 1 hour 20 mins to do the setup … down to the point wherte it says
    OK Lets Do It !!
  • a further 9 hours to write the images and check them, including fsck
    of source partitions and desstination.
    and
    it is not quite finished … expecting another hour of checking. I (I am on the spare PC)

So what is the conclusion?

  • The original topic problem of taking >3 hours to setup is solved … it was due to the failing disk
  • Clonezilla still takes an awesome amount of time to backup 12 partitions from my SSD. It writes at around 4-5 Gb/min when the internal hardware is supposed to be capable of 6Gb/sec . It must be limited by the USB3 link to the external disk.
    I am thinking about using removable internal disks for backup
  • More than an hour to setup still seems a bit long too. It spends a lot of time finding disks and partitions. I might try an earlier or a later version
    of Clonezilla

Overall, though, I am happy with finding the failing disk. It is strange that Clonezilla was affected, but not any of my Linuxes or VM’s that were on the failing disk?

Thank you again
Neville

6 Likes

Well done that man !
You must have a lot of data with so much time and disks involved
Bravo !

3 Likes

Too many Linux distros and VM’s
I need to finish a few jobs and get rid of some things

1 Like

Perhaps a good start, normally when i tidy up i think guard just in case … garage full of junk !

2 Likes

I noticed, that on my Ventoy drive I have a clonezilla image. As I had to modify partition layout, had to reboot anyway, so I looked at Clonezilla before entering to Gparted live.

I did not do anything with it, but let it boot. It was standing there waiting for my input, what I want to do; disc to image, etc.
I could switch to other tty’s flawlessly, and switch back to Clonezilla.
So there are no windows, but there are more consoles, Clonezilla ran on tty1, I could switch over to tty2…6 by pressing ctrl-alt.F2…6.
Switching back to tty1 by pressing ctrl-alt-F1 brings clonezilla to the foreground again.

2 Likes

Right, I did not think of that. Thanks Laszlo

Hi László, :wave:

Thanks for mentioning this fact.
I never knew that, despite using clonezilla for years now.

I learnt something new again :wink: .

Cheers from Rosika :slightly_smiling_face:

2 Likes