I wrote a script for this using umount and hdparm suspend. Feel free to edit the script and use at your own risk. The script is interactive or can be run with options.
CloneZilla can do the job. Gparted could help.
From clonezilla.org :
Clonezilla is a partition and disk imaging/cloning program similar to
True Image® or Norton Ghost®. It helps you to do system deployment,
bare metal backup and recovery. Three types of Clonezilla are
available, Clonezilla live, Clonezilla lite server, and Clonezilla SE
(server edition). ...
Here's how I'd approach it.
Dump the partition table for an old disk: sfdisk -d /dev/sda > sda.dump
Edit the resulting file to match the new disk size (partitions start should be divisible by 2048), replace sda with sdb, e.g. using sed.
Restore the partitions on a new disk sfdisk /dev/sdb < sda.dump
Use e2image to copy ext2/3/4 partitions (e.g. ...
Edit: would this work for a SSD just like for a HDD?
dd if=/dev/urandom of=/dev/sdc bs=1M count=2
Sure, that works by writing over the first 2 MB of the drive, which probably includes the partition table and the start of the first partition, which often starts at 1 MB.
Most of your files and the intact filesystems of any other partitions would still be ...
Not only is shred a bad tool for erasing an SSD, it won't work as intended. As others have noted, overwriting specific data blocks on an SSD is generally not possible, because wear-leveling means that "overwritten" blocks won't necessarily be actually-written to the same physical hardware memory cells. So, there's no point in bothering with ...
Writing a block to an SSD does not overwrite the old block. That's because all recent SSDs use something called "wear leveling".
To write a block to an SSD, you need to erase it first, and then you can write the new data. But erasing is an operation that can only be executed a limited number of times; each time you do an erase, you "weaken&...
It's better to have a boot partition for Linux on your SSD and 512MB will be enough.
It's OK to have /home on your HDD (that won't slow down boot significantly).
If you don't expect to have many gigabytes worth of MySQL (or any other DB) data there's no need to have a separate partition for /var. Likewise for /opt. It's not clear what you'll be running.
This is the fastest way to securely erase a drive I know of.
For SSDs, no, it's not.
blkdiscard /dev/device is dozens times faster and should be equally safe for your use case.
Would cat /dev/zero > /dev/sdX be as fast?
From the look of it these two commands should be equally fast.
Fast is what I need while not decreasing the SSD's life span.
You do ...