[KDE] Can no longer clone with Clonezilla HELP

[GregM]

Went to do a back up of my 120gb SSD drive using Clonezilla and it keeps stopping and failing to clone.
These are the same two SSD drives I have done before, a 120gb to 240gb.
I also tried my 120gb to a 128gb SSD and get the same problem.

Is there some kind of "check disk" type software I can inspect my 120gb drive with to make sure it's ok?
This is the drive that I just booted up with and am running now.

What can I be doing wrong?
This has me somewhat scared.
Could this be some kind of virus?

Help!

[GregM]

Never mind
I guess I grabbed an older version of Clonezilla.
Threw that away and found the right version.
It just worked on this backup.

[GreyGeek]

How long did it take for Clonezilla to back up your 120Gb drive? (Just asking for a friend! )

[GregM]

About 10 minutes

[GreyGeek]

That's not bad. I assume you can continue your other activities while the clone is working in the background.

When I was sending both the @ and @home BTRFS snapshots to remote storage the @ would take about 4-6 minutes and the @home would take about 6-8 minutes, for a total of 10-14 minutes. I didn't see any advantages in keeping @home as a separate subvolume so I merged it with @, which required sending only one snapshot to remote storage. When I switched to incremental backups my time reduced from 10+ minutes to usually less than 15 seconds. I just fire my script and go about my business.

A while back I deleted Minecraft and several maps from my system. Then I did some balancing and scrubbing, reducing my disk usage from 150GB to 111GB. Now my incremental backups are done in about 10 seconds.

[GregM]

I really can't do anything while Clonezilla is running as it's boots to itself off a disk and nothing else is running.
I don't mind at all. I should do it more.

I would be interested in learning/doing incremental backups though.

[oshunluvr]

GG - there is a clonezilla application ( vs. bootable image ) that will let you clone an UNMOUNTED file system or partition, but you can't access it during the operation obviously.

If one was to use rsync to backup files, you could still access them during the backup but it would take many more hours than clonezilla. Also, I'd advise against accessing the data whist being copied as you may inadvertently edit a file during the copy operation effectively trashing it.

GregM - As GG and I have opined often on this forum, the greatest benefit to BTRFS is the snapshot ability and by extension the ability to send these snapshots to other devices - all while still using the file system - i.e. no rebooting or waiting for it to finish, it does that in the background. The need for any external utility goes away. The one possible downside is since the backup is a read-only snapshot of the file system it requires an equal amount of space as the original (compression occurs naturally in the BTRFS filsystem via a mount option). The counter upside is since the files are stored in their native format (not compressed or archived), they are accessible from the backup just like any other file.

[GreyGeek]

GregM - Unfortunately, the ability to do incremental backups has not been added to Clonezilla, and I doubt that it ever will be added.

OL- I haven't written much about rw snapshots, except to say that when using a ro snapshot to replace/recover the bootable subvolume, @, one must convert it to a rw snapshot in the process. However, since merging @home into @, I created a rw snapshot, called @wr_bkup, which contains the COW files that a ro snapshot wouldn't contain, since an ro snapshot is a static image of the files system at the moment the snapshot is taken.

It may be that a file I inadvertently edited or deleted is in a ro snapshot in some form, if it existed at the time the ro snapshot was made. I may be able to restore it to the condition it was in when that snapshot was made because of COW (copy on write). With @wr_bkup the previous condition of the file is saved to @wr_bkup when I change the file. If I want to revert to the previous condition for any reason I just pull it out of @wr_bkup and overwrite the current file with it.

[oshunluvr]

I usually store my daily snaps as RW and my weekly backups as RO. I do it this way as a matter on convenience. Since I'm more likely to use a daily snapshot to "roll back" it needs to be RW for that. If I'm restoring from a backup I have to "send" it thus it needs to be RO for that function.

Really, it makes little difference as a single command set the RW/RO status.

[GreyGeek]

The btrfs property command has a warning:

Important: don't use btrfs property set to make a subvolume read-write after restoring. This is a low-level command, and leaves "Received UUID" in a false state which causes btrbk to fail on subsequent incremental backups. Instead, use btrfs subvolume snapshot (without -r flag)...

Every since I read that I've moved a snapshot to @ using
btrfs su snapshot /mnt/snapshots/@yyyymmdd /mnt/@
instead of
btrfs property set -ts /path/somesnapshot ro false