shasheene
commented
1 week ago Thanks for the report. I have received surprisingly large number of reports about this recently.
Typically the advice I give is to first do a filesystem check on the source disk, and ensure no issues.
In the past, users have sometimes avoided the issue by trying different destination disks (eg, different external USB drive or different network share protocol). Similar issues can happen when using the 32-bit "Bionic" release on high RAM system.
One user recently had a similar sounding issue and it worked when 'Rescue' mode was ticked.
The fact the transfer rate steadily declines indicates that the partclone utility running internally is still operating. It's partclone that generates those transfer estimates. So for what it's worth I can suggest the issue is almost certainly between partclone and its interaction with your source filesystem and destination filesystem -- rather than a Rescuezilla specific bug.
Still, any bug impacting users is of course my problem -- especially given this slow down / failed backup issue is relatively widespread it appears.
Also (thinking aloud about a technical note) -- I wonder if a long-standing Rescuezilla build issue (task #150) could actually contributing to this issue (and other failures) in only a Rescuezilla environment but not in say, Clonezilla -- due to partclone expecting shared libraries to be present that are missing etc.
My new PC: Lenovo IdeaCentre AIO 3 27IAP7, 12th Gen Intel® Core™ i5-12450H × 12, 64 Bit, 16 GB RAM, 1 TB SSD. OS: Linux Ubuntu version 24.04 LTS (Noble Numbat), GNOME 46, Linux 6.8.0-36-generic. Backup HD: Lenovo USB 3.0 256 GB. 100 GB available. Source file on the Lenovo is about 60 GB in size. . Problem with RZ: After starting the backup, the transfer rate is about 14 GB/min as shown on RZ and steadily declines to about 2 GB/min over 10 mins. When the backup reaches about 53% complete, the backup stops and will not complete. I used the default compression level that RZ had set.