Migrate your Debian 10 installation to a new 500GB SSD by booting from a live USB, creating three partitions on the new drive, and using
rsync to copy your data while preserving permissions. This method ensures your system remains bootable and functional without requiring a fresh installation.
Preparation and Live Environment
Before beginning the migration, ensure you have a backup of critical data, as disk operations carry inherent risks. You will need a bootable Debian Live USB or any Linux-based rescue medium that can access both your old hard drive and the new 500GB SSD. Connect the new SSD to your system via SATA or M.2 slot if it is not already installed. Boot from the live USB and select "Try Debian" to enter the desktop environment without installing anything. Open a terminal window immediately, as most configuration steps require root privileges.
Identify your drives using the
lsblk command. Typically, your old drive will be identified as
sda or
nvme0n1, while the new empty SSD will appear as
sdb or
nvme1n1. Verify this carefully; writing to the wrong device will erase your existing system. For this guide, we assume the old drive is
/dev/sda and the new target is
/dev/sdb. If you are unsure about partition schemes, consider checking
Backup and Restore Partition Information for Ubuntu LUKS LVM on a 250GB SSD for general principles of disk identification, although the commands differ slightly for non-LVM setups.
Partitioning the New SSD
The summary specifies creating three new partitions. A standard Debian installation typically requires a boot partition, a root partition, and optionally a swap partition. Use
fdisk /dev/sdb to begin partitioning. First, create a small FAT32 partition for the BIOS/UEFI boot sector. Set its size to approximately 512MB and change its type to
ef00 for UEFI systems or
83 for legacy BIOS. Next, create a second partition for the root filesystem (
/). Allocate the majority of the remaining space to this partition and format it with ext4. Finally, create a third partition for swap space. The size should match your RAM capacity or follow standard guidelines, such as 2GB for systems with less than 4GB of RAM.
After creating the partitions, label them appropriately using
parted or
e2label. Label the boot partition
boot, the root partition
root, and the swap partition
swap. This makes subsequent mounting steps more intuitive. Format the boot partition with
mkfs.vfat /dev/sdb1, the root partition with
mkfs.ext4 /dev/sdb2, and initialize the swap space with
mkswap /dev/sdb3. Do not format the boot partition if you plan to use GRUB directly on the MBR, but for modern GPT disks, a separate EFI System Partition is required.
Mounting and Data Transfer
Create mount points for the new partitions. Run
mkdir -p /mnt/new_root/boot to establish the directory structure. Mount the root partition first:
mount /dev/sdb2 /mnt/new_root. Then mount the boot partition:
mount /dev/sdb1 /mnt/new_root/boot. If you created a swap partition, you do not mount it in the traditional sense; instead, activate it later or configure the fstab. Now, synchronize your data. Use
rsync to copy files from the old root to the new one. Execute
rsync -aAXv --exclude=/proc --exclude=/sys --exclude=/dev / /mnt/new_root. The flags ensure that permissions, ACLs, and extended attributes are preserved, which is crucial for system stability.
This process may take some time depending on the amount of data. Once complete, verify the contents of
/mnt/new_root to ensure essential directories like
etc,
home, and
var are present. If you encounter permission errors during rsync, ensure you are running the command as root. For users dealing with complex package issues after migration, refer to
Fixing E: Sub-process /usr/bin/dpkg returned an error code (1) on Kali Linux, as similar dependency resolution techniques apply when chrooting into the new environment.
Configuring Bootloader and fstab
Chroot into the new environment to update the bootloader and filesystem table. Install necessary tools if missing:
apt-get install grub-pc grub-common (for BIOS) or
grub-efi-amd64 (for UEFI). Update the
fstab file located at
/mnt/new_root/etc/fstab. Replace UUIDs or device names to point to the new partitions on
/dev/sdb. You can find the new UUIDs using
blkid. Incorrect fstab entries will prevent the system from booting.
Install GRUB to the new disk. For BIOS systems, run
grub-install /dev/sdb. For UEFI, mount the EFI partition to
/boot/efi inside the chroot and run
grub-install --target=x86_64-efi --efi-directory=/boot/efi. Finally, update the GRUB configuration with
update-grub. This scans the new partitions and creates a boot menu compatible with the new hardware layout.
Finalizing the Migration
Exit the chroot environment and unmount the partitions:
umount /mnt/new_root/boot followed by
umount /mnt/new_root. Shut down the computer and remove the live USB. Disconnect the old hard drive to prevent accidental boot conflicts, then power on the system. The BIOS/UEFI should now detect the new SSD as the primary boot device. Select it from the boot menu. If successful, Debian 10 will load from the new 500GB SSD with all your data intact. Log in and verify that network settings, user accounts, and applications function correctly. Reconnect the old drive only after confirming the new system is stable, using it as a secondary storage device or for archival purposes.
Frequently Asked Questions
What happens if I select the wrong drive during rsync?
You will overwrite the contents of the selected drive with the source data, potentially causing significant data loss. Always double-check your
lsblk output before specifying source and destination paths in the rsync command.
Can I keep my old hard drive connected during the migration?
Yes, but you must ensure your BIOS/UEFI boot order prioritizes the new SSD. Keeping both drives connected allows you to use the old one as a backup if the migration fails, but it can complicate UUID detection in fstab.
Do I need to reinstall drivers for the new SSD?
Generally, no. Standard NVMe and SATA controllers are handled by the kernel modules included in Debian 10. However, if you use proprietary firmware, ensure it is installed within the chroot environment before rebooting.
Why did my system fail to boot after changing fstab?
Incorrect UUIDs or missing mount points in
/etc/fstab are the most common causes. Use a live USB to edit the file again, verifying UUIDs with
blkid against the actual partition labels.
Is it safe to delete the old partitions immediately after migration?
No. Wait until you have fully tested the new SSD for stability, performance, and application compatibility. Only delete old partitions once you are confident the new setup is reliable.