Comments (8)
The FOG Project implementation of the shrinking feature described in the previous comment is a very inefficient and roundabout way that makes both the backup and restore operations really slow. It's much more efficient to implement the feature as follows:
- Fix remaining problems in the partclone-utils project (which will also improve the beta Image Explorer’s low-compatibility)
- This will unlock the ability of any partclone image to be expressed as a regular block device
- Create the filesystem on the destination disk (with the same partition flags as the source, as usual), mount the partclone-utils block device and the destination filesystem, and simply copy files in using a tool like
rsync
.- The biggest "gotcha" I foresee is the unique UUID identifiers will be regenerated and will need to be carefully handled to avoid causing compatibility issue compared to existing block-level approach.
Despite all the work it will require, the payoff seems worthwhile: automatic resizing when restoring or cloning to disks of smaller capacity to the original will be a powerful feature.
from rescuezilla.
Exactly. The backup.tgz
that you describe is an archive of all files on your system, and the approach you describe involves partitioning the disk, copying the files in and then modifying GRUB bootloader.
This is the approach I will implement for Rescuezilla. It uses partclone-utils to mount the backup image's existing partclone files before doing any copying, so that backups created by any supported image format automatically become able to be restored to disk smaller than original.
(This feature is something that no other open-source disk imaging and cloning tool has yet implemented. Not even Clonezilla. FOG Project's roundabout implementation of this feature using "Single Disk - Resizable image format" is way too slow and doesn't use this approach)
from rescuezilla.
Clonezilla's "-r" argument can only be used to grow filesystems to fit into their partitions, it cannot shrink partitions or filesystems:
If the target disk size is larger than the source disk, you can try to use option "-k1" which will create the partition table proportionally in the target disk and turn on option "-r" to resize the filesystem in the partition automatically. This is useful to make use all of the target disk size.
Also from the Clonezilla FAQ:
Q: Why Clonezilla can NOT restore an image which is saved from a large drive to a smaller drive? Any workaround?
A: It's not easy to implement such a feature, since Clonezilla now is a partition "imaging" tool, by "imaging", it means clonezilla actually does not know the files themselves, clonezilla just knows where the used blocks are. Because of this reason, the target partition size must be equal or larger than the original one so that clonezilla can restore the used blocks on that partition. If the target partition size is smaller, then it will go wrong.
Unless Clonezilla has file-based function in the future. Maybe...
If you really still want to make this, check this FAQ, the doc here, this forum or the program fsarchiver.
and another entry:
Q: Is that possible I can restore to smaller HDD when the image was taken from bigger one? Or to clone a larger disk to a smaller one?
A: This is always a challenge to Clonezilla because it's block-based tool, not file-based one.
Two possible solutions:Method 1: If you are sure the used data blocks on the source disk are within the disk boundary of destination one, yes, it's possible to make that with the options "-k1" and "-icds" enabled in the expert mode.
Method 2: Use Clonezilla live >= 2.6.7-28 or 20200703-focal. For older version it does not always work.
- First use GParted live to resize the source disk, and make all partitions to be equal to or smaller than the size of destination disk.
- Then boot Clonezilla live.
Given Rescuezilla's recent addition of Image Explorer (beta) support, there might be a (complex) pathway to implement this. However this doesn't sound like a great solution.
from rescuezilla.
Deleted comment that was a duplicate of this comment
from rescuezilla.
Growing partitions is easy to implement. All Rescuezilla would need to do is restore the partition table and partclone backup, then use the correct programs to grow the partition and filesystem. For completeness, Clonezilla's implementation in growing the filesystem is found in sbin/ocs-resize-part
. Here are the filesystem supported:
- reiserfs (via
/sbin/resize_reiserfs
of reiserfsprogs package) - vfat|fat16|fat32 (
/usr/sbin/fatresize
from fatresize package) - ext2|ext3|ext4 (via
/sbin/resize2fs
of e2fsprogs package) - ntfs (via
/sbin/ntfsresize
of ntfs-3g package) - xfs (via
/usr/sbin/xfs_growfs
of xfsprogs package) - jfs (via
mount -o remount,resize
- btrfs (via
btrfs filesystem resize max
) - nilfs2 (via
/usr/sbin/nilfs-resize
of nilfs-tools package)
As best I can tell, Clonezilla doesn't first modify the partition table other than relying on a partition table proportional restore. Rescuezilla v2.2 implements this sbin/ocs-resize-part
behavior faithfully, but achieving the ability to automatically grow and shrink the filesystems across all supported image formats would be much more useful.
One of the key features of FOG Project is the ability to restore to disks smaller than original. FOG Project mostly relies on partclone (like the industry-standard Clonezilla format that Rescuezilla uses) but uses different metadata so FOG Project images have only recently become supported by Rescuezilla. I have noticed that FOG Project images often have a modified sfdisk partition table backup, which presumably provides flexibility in how the partition table is restored. According to the FOG Project wiki describing its Single Disk - Resizable image format, it appears FOG Project's default settings is to make a dd backup of all partitions, then shrink the dd backup, then make a partclone backup of that data before finally deleting the unnecessary dd backup:
This is the default choice used by FOG as it works in most cases and allows for deployment to smaller size disks as well. It takes a copy of every partition on the disk, and resizes partitions that has excessive free space to a smaller size where possible. Each resizable partition will go through a "Resizing filesystem" process for each partition that is to be resized. This process can take some time depending on how severe disk fragmentation is. The partitions that are shrank will be shrunk down to only 2GB of free space on their partition. This allows an image taken from a 6TB drive with only 20GB of used space to be deployable to a drive with a total capacity of 25GB roughly. When the partitions are laid onto the destination drive, all resized partitions are intelligently expanded to utilize the entire drive.
Given Rescuezilla's primary goal is to be fully compatible with the industry-standard Clonezilla format, it does not make sense for Rescuezilla generate backups uses the exact approach taken by FOG Project, because custom logic needed to expand the images won't be available in Clonezilla, and would therefore break Rescuezilla's full Clonezilla interoperability. Also because Rescuezilla supports all the partclone-based imaging formats (Clonezilla, Redo Backup and Recovery, FOG Project, Redo Rescue and Foxclone), almost all input images will not be pre-shruken. So a different approach to FOG Project is required.
So for deploying non FOG Project images, it may be possible to stream the output of partclone into the relevant filesystem resizing application, but this relies on piping the output between applications. Given streams do not provide random access this may not be easy. Side note: I need to further investigate how FOG Project is able to pre-shrink images.
Right now the cleanest approach might be associating the partclone image to a block device using partclone-utils and either operating on the block device using the shrink filesystem commands, or mounting the block device and copying files to the destination. The advantage of this approach is it would exercise some code paths that gets tested widely with Rescuezilla Image Explorer, including the planned indexed compression archive functionality. This approach will of course first require a lot of work to make partclone-utils more robust.
from rescuezilla.
I have tried to restore the system to a small hard disk using the following methods
Backup system:
tar Pzcfp backup.tgz --exclude=/proc --exclude=/mnt --exclude=/lost+found --exclude=/sys --exclude=/media --exclude=/run --exclude=/boot --exclude=/dev --exclude=/var/spool/postfix /
Restore the system:
By starting the U disk system, manually partition the disk, and decompress the system backup files (About 3-5 minutes)
tar zxf backup.tgz
Repair GRUB :
Populate GRUB with the obtained UUID:
blkid
vim /boot/grub/grub.conf
root="obtained UUID"
vim /etc/fstab
uuid="obtained UUID"
Under the Centos7 system, it can be used normally.
from rescuezilla.
It will be great if Rescuezilla support this feature. I think Foxclone does, according to its manual page 23. https://foxclone.org/downloads/foxcloneV51.pdf
from rescuezilla.
@alphanis Foxclone appears to only support this with the same manual workaround as the current version of Rescuezilla. From that project's manual:
from rescuezilla.
Related Issues (20)
- Discord or IRC Help HOT 1
- I can help improve Rescuezilla website if project's owner wants HOT 1
- Rescuezilla cannot auto detect the max size of USB while writing image HOT 1
- Possibility to keep partition LABEL when cloning
- Can't boot via ventoy HOT 6
- Error opening image file HOT 6
- Can not boot Windows 7 MBR version after restore it from Rescuezilla Image on Macbook HOT 1
- Is possible update the kernel in ISO ? HOT 3
- Feature Request : Add WOL function
- Feature Request: Using the bootkey to store the image HOT 2
- Remote cloning? HOT 1
- creating rescue partition for rescuezilla in Fedora 39 (NOT Ubuntu) HOT 1
- Donations link HOT 2
- Add caffeine package
- [req] Add SKIP button to auto-search
- Hide empty disks HOT 1
- [critical] Users report failed clone (and backup) caused working Windows to break HOT 8
- RHEL 8 backup freezes HOT 1
- Restoration to smaller SSD not possible (Mac) HOT 3
- can't boot Rescuezilla as a rescue partition from grub2 HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rescuezilla.