this post was submitted on 23 Feb 2024
98 points (100.0% liked)

Linux

48746 readers
1136 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
98
Is Clonezilla still a solid choice for complete backup and restoration of partition(s) / drive(s) nowadays? (lemmy.ml)
submitted 10 months ago* (last edited 10 months ago) by [email protected] to c/[email protected]
44 comments fedilink hide all child comments
 

My dear lemmings,

I discovered Clonezilla a while ago and it still is my main tool to backup and restore the partitions I care about on my computers.

I cannot help but wonder if there are now better, more efficient alternatives or is it still a solid choice? There's nothing wrong with it, I'm just curious about others' practices and habits — and if there was newer tools or solutions available.

Thank you for your feedback, and keep your drives safe!

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 2 points 10 months ago (2 children)

The big advantage of Clonezilla or using dd is you make a perfect 1:1 copy of the disk so you're pretty confident it will restore perfectly, but you need a disk of at least the same size and so on. Also perfect if you're trying to do file recovery and so on, because even corrupted or entirely unreachable data is still technically on the disk.

That's very inefficient when you have say, 5GB used of a 1TB disk, although compression will help a bit. But that's where more specialized tools comes in: what if we could only backup the actual data, and end up with a 5GB backup before compression.

That's useful and nice, but can't possibly deal with corrupted or deleted files since it'll just skip over them. The backup is only as good as all the filesystem features the archiver can encode. On Linux, tar has us pretty well covered as long as you only need relatively standard features like owners, groups. If you zip your root Linux partition you'll end up with broken ownership and permissions, because it doesn't encode ACLs and xattrs and hardlinks and whatever else. On NTFS, since it's proprietary, undocumented and a fairly complex filesystem, it's much riskier. If you backup your game library, you're probably fine, but if you want Windows to boot after a restore, you need a much more complete backup and if you don't want to take risks, whole partition backups are much safer. ntfsclone exists but I just don't trust it like I would trust tar to backup my ext4 partitions correctly.

So it's all a tradeoff. Do you want efficiency, or do you want reliability? How much of the information can you lose? Like, if you backup your C: drive on Windows but only care about your files and documents but not the Windows install itself, then it makes sense to just archive the files rather than a block copy.

So, what do you expect from your backups? The answer to that question also answers this thread.

[–] [email protected] 1 points 10 months ago (3 children)

for a large drive with only partial data you can make dd quicker by reducing partition size. Then fdisk to list byte size of (cylinders x bytes) in header output, and units listed for end of partition. you then use dd with bs=(cyl x bytes) count=(units+1) so dd stops at the last block of partition. once copied you can resize partition. it is how I fit a duplicate of my nas OS img on a 4 gig USB stick img for redeploy. DD is faster and then resize partitions after

[–] [email protected] 1 points 10 months ago (1 children)

That... seems pretty unsafe. If I'm taking a backup, I definitely would avoid resizing it or making any modifications to it during the backup process. What if the resize fails and is the reason you need to restore from backup in the first place?

I guess it's a handy hack in use cases like yours, or if the backup is a convenience, but it's important to understand the risks and whether you're better off with filesystem level tools.

[–] [email protected] 1 points 10 months ago

I'm sure there is potential risk, It just hasn't been a problem on my end. Just putting out as an option if you don't want to clone a 16TB drive and want to fit it on a drive that suits it.

[–] [email protected] 1 points 10 months ago (1 children)

You'd probably be better off with dd if=/dev/zero of=file.zero to zero out empty space, dd copy the whole drive, then compress the copy. I wouldn't fuck around with partitions on something I want to back up

[–] [email protected] 1 points 10 months ago (1 children)

For sure, but in my case I didn't want a copressed copy, I wanted a working fully functional drive image

[–] [email protected] 1 points 10 months ago (1 children)

Probably safer to image the whole partition then shrink the image, then. Not sure exactly how I'd go about it, but I'm sure it's not too bad, probably three arcane shell commands

[–] [email protected] 1 points 10 months ago

Yes, zero spacing and compress. In my case I was building a direct clone backup for when nas might fail and I can swap drive innediately, but did not want to wait hours to dd the empty drive to an image file.

[–] [email protected] 1 points 10 months ago* (last edited 10 months ago)

Reposted from a server fault thread , author plasmapotential. note fdisk -l -u=cylinders /dev/sdX will output cylinder info if it doesnt by default.

Use dd, with the count option.

In your case you were using fdisk so I will take that approach. Your "sudo fdisk -l "produced:

Disk /dev/sda: 64.0 GB, 64023257088 bytes
255 heads, 63 sectors/track, 7783 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0000e4b5

Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          27      209920   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2              27         525     4000768    5  Extended
Partition 2 does not end on cylinder boundary.
/dev/sda5              27         353     2621440   83  Linux
/dev/sda6             353         405      416768   83  Linux
/dev/sda7             405         490      675840   83  Linux
/dev/sda8             490         525      282624   83  Linux

The two things you should take note of are 1) the unit size, and 2) the "End" column. In your case you have cylinders that are equal to 8225280 Bytes. In the "End" column sda8 terminates at 525 (which is 525[units]16065512 = ~4.3GB)

dd can do a lot of things, such as starting after an offset, or stopping after a specific number of blocks. We will do the latter using the count option in dd. The command would appear as follows:

sudo dd if=/dev/sda of=/your_directory/image_name.iso bs=8225280 count=526

Where -bs is the block size (it is easiest to use the unit that fdisk uses, but any unit will do so long as the count option is declared in these units), and count is the number of units we want to copy (note that we increment the count by 1 to capture the last block).