Migrate Linux server data to a Selectel cloud server using dd

Last update: October 16 2026Open in Markdown

You can migrate a Linux server to a Selectel cloud server using the dd utility.

The dd utility copies the entire disk contents along with the operating system, settings, and data. During copying, disks and network bandwidth will be fully utilized. After the migration, you only need to update the parameters that depend on the hardware and network: partition IDs, network settings, and IP addresses in the service configurations.

Migrate data in one of two ways:

• with stopping the source server — both servers boot into Rescue mode, data does not change during copying, and the copy is completely consistent. The work can be carried out at night or on weekends;
• without stopping the source server — the source server continues to run, and databases and actively changing files are migrated separately after copying the disk.

If intensive disk writes occur on the source server, we recommend migrating Linux server data to a Selectel cloud server using rsync.

To migrate data:

1. Create a cloud server.
2. Prepare the Linux server.
3. Migrate data using the dd utility.
4. Check and switch services.

1. Create a cloud server

Use the Create a cloud server instructions. The disk size of the new server must not be smaller than the original one.

2. Prepare the Linux server

1. Estimate the copy time. To do this, divide the server disk size by the link speed between the servers. You can measure link speed using the iperf3 utility. For example, a 500 GB disk at 100 MB/s takes about an hour and a half to copy.

2. Back up data and databases on the source server.

3. Save the list of running services and open ports on the source server to compare the list with the new server:

   systemctl list-units --type=service --state=running > <service_file_name>.txt
   ss -tulpn > <ports_file_name>.txt

   Specify:

   • <service_file_name> — the name of the file to save the service list. For example, services-before;
   • <ports_file_name> — the name of the file to save the port list. For example, ports-before.

4. 24 hours before switching, reduce the TTL of domain DNS records to 300 seconds.

3. Migrate data using the dd utility

With stopping the source server

1. Boot the source and new servers into Rescue mode.

2. Connect to the source and new servers in Rescue mode.

3. Check the disk names on both servers:

   lsblk -o NAME,SIZE,TYPE,MOUNTPOINT

   The response will display information about the disks. For example:

   NAME     SIZE TYPE MOUNTPOINT
   sda        8G disk 
   ├─sda1     8G part /
   └─sda14    8M part 
   sr0      488K rom 

   Where sda is the disk name.

4. Start copying from the source server:

   dd if=<source_disk> bs=32M status=progress | ssh root@<new_ip_address> "dd of=<target_disk> bs=32M"

   Specify:

   • <source_disk> — name of the disk on the source server that you checked in step 3. For example, /dev/sda;
   • <new_ip_address> — public IP address of the new server;
   • <target_disk> — name of the disk on the new server that you checked in step 3. For example, /dev/sdb.

   If the entire bandwidth should not be occupied by copying, limit the rate with the pv utility. For example:

   dd if=/dev/sda bs=32M status=progress | pv -qL 90M | ssh root@203.0.113.16 "dd of=/dev/sdb bs=32M"

   Where 90M is a data transfer rate limit of up to 90 MB/s.

5. If copying is interrupted, resume data transfer:

   5.1. Check the number of completely transferred blocks of size bs in the dd utility output after the copy was interrupted. For example:

   ^C244234+0 records in
   244233+0 records out
   8195099590656 bytes (8.2 TB, 7.5 TiB) copied, 271390 s, 30.2 MB/s

   Where 244233 is the number of completely transferred blocks of size bs.

   If the disk was copied to an image file and the output of the dd utility was not preserved, divide the file size in bytes by the block size (32 MB = 33,554,432 bytes) and take the integer part.

   5.2. Continue data transfer:

   dd bs=32M skip=<records_out> if=<source_disk> status=progress | ssh root@<new_ip_address> "dd bs=32M seek=<records_out> of=<target_disk>"

   Specify:

   • <records_out> — number of completely transferred blocks that you obtained in step 5.1;
   • <source_disk> — name of the disk on the source server;
   • <new_ip_address> — public IP address of the new server;
   • <target_disk> — name of the disk on the new server.

6. Exit Rescue mode on the new server.

7. If the OS on the new server does not boot, check the UUIDs and partition names:

   7.1. Boot the new server into Rescue mode.

   7.2. Check partitions and fstab:

   blkid
   mount <root_partition> /mnt
   cat /mnt/etc/fstab

   Specify <root_partition> — the name of the root partition. For example, /dev/sda1.

   7.3. Fix UUIDs or partition names in the /mnt/etc/fstab file. 7.4. Optional: to restore the bootloader, reinstall it:

   for d in dev proc sys; do mount --bind /$d /mnt/$d; done
   chroot /mnt
   grub-install <target_disk>
   update-grub    # on RHEL-based distributions: grub2-mkconfig -o /boot/grub2/grub.cfg
   exit

   Specify <target_disk> — the disk name on the new server. For example, /dev/sda.

8. Update network settings on the new server: IP address, subnet mask, gateway.

9. Find configuration files that contain the public IP address of the source server:

   grep -rl "<old_ip_address>" /etc

   Specify <old_ip_address> — the public IP address of the source server.

10. In the found files, replace the public IP address of the source server with the new one.

11. Exit Rescue mode on the new server.

12. Compare the list of running services and open ports on the new server with the list you saved in step 2.

13. Optional: to keep data up to date during testing, configure database replication from the source server.

Without stopping the source server

warning

If there is a DBMS on the source server, we do not recommend transferring data while it is running. During data transfer, the DBMS will continue write operations to its files, causing some data on the new server to become inconsistent — the database will not start or will be corrupted. Before running dd, stop the DBMS for the duration of the copy or migrate the databases separately using a dump or replication.

1. Boot the new server into Rescue mode.

2. Connect to the new server in Rescue mode and to the source server.

3. Check the disk names on both servers:

   lsblk -o NAME,SIZE,TYPE,MOUNTPOINT

   Information about disks will appear in the output. For example:

   NAME     SIZE TYPE MOUNTPOINT
   sda        8G disk 
   ├─sda1     8G part /
   └─sda14    8M part 
   sr0      488K rom 

   Here sda is the disk name.

4. Start copying from the source server:

   dd if=<source_disk> bs=32M status=progress | ssh root@<new_ip_address> "dd of=<target_disk> bs=32M"

   Specify:

   • <source_disk> — the disk name on the source server that you checked in step 3. For example, /dev/sda;
   • <new_ip_address> — the public IP address of the new server;
   • <target_disk> — the disk name on the new server that you checked in step 3. For example, /dev/sdb.

   If the entire bandwidth should not be occupied by copying, limit the speed using the pv utility. For example:

   dd if=/dev/sda bs=32M status=progress | pv -qL 90M | ssh root@203.0.113.16 "dd of=/dev/sdb bs=32M"

   Here 90M is the data transfer rate limit of up to 90 MB/s.

5. If copying was interrupted, resume the data transfer:

   5.1. Check the number of fully transferred blocks of size bs in the output of the dd utility after copying was interrupted. For example:

   ^C244234+0 records in
   244233+0 records out
   8195099590656 bytes (8.2 TB, 7.5 TiB) copied, 271390 s, 30.2 MB/s

   Here 244233 is the number of fully transferred blocks of size bs.

   If the disk was copied to an image file and the output of the dd utility was not saved, divide the file size in bytes by the block size (32 MB = 33,554,432 bytes) and take the integer part.

   5.2. Continue the data transfer:

   dd bs=32M skip=<records_out> if=<source_disk> status=progress | ssh root@<new_ip_address> "dd bs=32M seek=<records_out> of=<target_disk>"

   Specify:

   • <records_out> — the number of fully transferred blocks that you obtained in step 5.1;
   • <source_disk> — the disk name on the source server;
   • <new_ip_address> — the public IP address of the new server;
   • <target_disk> — the disk name on the new server.

6. Exit Rescue mode on the new server.

7. If the OS failed to boot or booted with errors due to active writing during copying, boot the new server into Rescue mode and repeat step 4.

8. If after repeated copying the OS still does not boot, check the UUIDs and partition names:

   8.1. Boot the new server into Rescue mode.

   8.2. Check partitions and the configuration file /mnt/etc/fstab:

   blkid
   mount <root_partition> /mnt
   cat /mnt/etc/fstab

   Specify <root_partition> — the name of the root partition. For example, /dev/sda1.

   8.3. Fix UUIDs or partition names in the /mnt/etc/fstab file. 8.4. Optional: to restore the bootloader, reinstall it:

   for d in dev proc sys; do mount --bind /$d /mnt/$d; done
   chroot /mnt
   grub-install <target_disk>
   update-grub    # on RHEL-based distributions: grub2-mkconfig -o /boot/grub2/grub.cfg
   exit

   Specify <target_disk> — the disk name on the new server. For example, /dev/sda.

9. Update network settings on the new server: IP address, subnet mask, gateway.

10. Find configuration files that contain the public IP address of the source server:

    grep -rl "<old_ip_address>" /etc

    Specify <old_ip_address> — the public IP address of the source server.

11. In the found files, replace the public IP address of the source server with the new one.

12. Exit Rescue mode on the new server.

13. Compare the list of running services and open ports on the new server with the list you saved in step 2.

14. Complete the database migration:

    • if replication is configured, wait for the replica to synchronize with the source server;
    • if replication is not configured, migrate databases using a dump.

15. To synchronize data that might have changed during copying, use the rsync utility:

    rsync -aAXH --numeric-ids --progress root@<old_ip_address>:<old_file_path> <new_file_path>

    Specify:

    • <old_ip_address> — the public IP address of the source server;
    • <old_file_path> — the path to the files on the source server;
    • <new_file_path> — the path to the files on the new server.

4. Check and switch services

For your information

During final data synchronization and switching between servers, service downtime occurs. We recommend synchronizing data and switching services during off-peak hours.

1. Check service operation on the new server before switching DNS. To do this, add an entry with the new IP to the hosts file on your local computer. This will allow you to connect to services on the new server while user requests continue to be routed to the source server:

   <new_ip_address> <domain> <subdomain>

   Specify:

   • <new_ip_address> — the public IP address of the new server;
   • <domain> — your domain name. For example, example.com;
   • <subdomain> — your subdomain name. For example, www.example.com.

   In Linux and macOS, the hosts file is located at /etc/hosts, and in Windows — at C:\Windows\System32\drivers\etc\hosts.

2. If services access their own domain, add the same entry to the hosts file on the new server.

3. If you find errors in service operation, fix them and repeat step 1.

4. Test services for 3 business days and address any issues if necessary.

5. Perform the final data and database synchronization.

6. Switch DNS records to the new IP.

7. Monitor service operation for another 3 business days.

8. If everything is working correctly, the source server can be shut down.