For my laptop full-backups I'm backing up images to a rotation of usb drives, each with a bootable clonezilla live partition and a larger ext4 library partition. Each clonezilla backup image is around 114G. I restore to a second laptop to confirm (fedora/linux on 2015 mac-book/mac-air). This system has worked very well for me (Thanks Steven + team!).
Recently I got a new laptop pair and so some challenges backing up on 2022 Dell restoring 2017 Vaio (also moving to luks encryption and btrfs).
backup/restore is working fine on just the Dell (when I select to encrypt the clonezilla image)
When I try to restore to the Vaio there's a change of internal drive name along with decrypting the clonezilla image seems to happen in the clonezilla live tmpfs
Working back to the Dell, restoring the clonezilla image instead to a flash drive using '1-2-mdisks restore_an_image_to_multiple_local_disks' i.e. choosing just one flash drive, provides similar error messages (attached) and has the best 32G Ram possibility I have for the tmpfs.
My best guess so far is that my backup image is too large (114G) to be processed in tmpfs /tmp, and such processing is required because of encryption + luks+ internal drive name change. I'd like to try providing a non-tmpfs location for this processing during restore?
Perhaps is there a way to add docker box regression to simulate multiple filesystems and option configurations for test puroposes. Maybe it would be more useful for me to do pre- work on tests instead rather than change this code which is flagged "# ///WARNING/// This program is really dangerous! You have to know what you are doing! Especially the destination disks!"
=> I'll have a think about where to go next. I do want to keep the luks/encryption.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The program "create-ocs-tmp-img" only copies those small files, and links the image files which are normally much bigger.
However, maybe some of the binary files, especially as you encrypted the image, are too big for your RAM...
Two workarounds for you:
Do not encrypt the image if you accept that.
Mount a partition which is large enough to /tmp. Just overwrite the original /tmp/ before you start to run Clonezilla.
Please let us know your result.
Steven
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Apologies missed your reply a few days, getting into the new year. I've made an un-encrypted image and also clearing/keeping the second laptop content so I can go that path...
Yep will report back.
Thanks again, S.
Last edit: Stephen Hawes 2023-01-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually I was able to reproduce this bug recently. The image for LUKS device should be linked, not copied. It's nothing to do with ecryptfs...
So I believe this issue is fixed in Clonezilla live >= 3.0.3-10 or 20230110: https://clonezilla.org/downloads.php
Please give it a try and let us know the results.
Thanks.
Steven
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The version I picked up was 3.0.3-22 and it worked a treat without any special provision. One further benefit I didn't expect is that the luks protection is retained all the way through to the second (vaio) laptop.
Thanks again and best regards,
Stephen
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For my laptop full-backups I'm backing up images to a rotation of usb drives, each with a bootable clonezilla live partition and a larger ext4 library partition. Each clonezilla backup image is around 114G. I restore to a second laptop to confirm (fedora/linux on 2015 mac-book/mac-air). This system has worked very well for me (Thanks Steven + team!).
Recently I got a new laptop pair and so some challenges backing up on 2022 Dell restoring 2017 Vaio (also moving to luks encryption and btrfs).
My best guess so far is that my backup image is too large (114G) to be processed in tmpfs /tmp, and such processing is required because of encryption + luks+ internal drive name change. I'd like to try providing a non-tmpfs location for this processing during restore?
Update: digging into sbin/ocs-restore-mdisks (ref: https://github.com/stevenshiau/clonezilla/blob/master/sbin/ocs-restore-mdisks#L317) it looks like use of /tmp is intentional to allow for CDR or FAT where no softlinks possible, later in sbin/create-ocs-tmp-img. I.e. a bit hairy to change.
Perhaps is there a way to add docker box regression to simulate multiple filesystems and option configurations for test puroposes. Maybe it would be more useful for me to do pre- work on tests instead rather than change this code which is flagged "# ///WARNING/// This program is really dangerous! You have to know what you are doing! Especially the destination disks!"
=> I'll have a think about where to go next. I do want to keep the luks/encryption.
The program "create-ocs-tmp-img" only copies those small files, and links the image files which are normally much bigger.
However, maybe some of the binary files, especially as you encrypted the image, are too big for your RAM...
Two workarounds for you:
Please let us know your result.
Steven
Apologies missed your reply a few days, getting into the new year. I've made an un-encrypted image and also clearing/keeping the second laptop content so I can go that path...
Yep will report back.
Thanks again, S.
Last edit: Stephen Hawes 2023-01-10
Actually I was able to reproduce this bug recently. The image for LUKS device should be linked, not copied. It's nothing to do with ecryptfs...
So I believe this issue is fixed in Clonezilla live >= 3.0.3-10 or 20230110:
https://clonezilla.org/downloads.php
Please give it a try and let us know the results.
Thanks.
Steven
Awesome Success! Thanks very much @steven_shiau!
The version I picked up was 3.0.3-22 and it worked a treat without any special provision. One further benefit I didn't expect is that the luks protection is retained all the way through to the second (vaio) laptop.
Thanks again and best regards,
Stephen
Great. Thanks for confirming that.
Steven