this post was submitted on 23 Feb 2024
98 points (100.0% liked)
Linux
48372 readers
2017 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
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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
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:
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:
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).
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.
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.
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
For sure, but in my case I didn't want a copressed copy, I wanted a working fully functional drive image
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
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.