How to best migrate to a bigger harddisk?

Operation
1

Hey Stevie,

I have been using syncosync without any relevant hiccups for years now, and still think it is a great solution! :+1: I really do not understand why not more people are picking it up …

Anyway, I would now want to migrate to a bigger harddisk (from 5 TB to 16 TB) and was wondering if I should start from scratch or if there is a reasonable way to copy data from the small HDD to the big one, then make sure all space is used and keep using the setup as is. Any advice? :slight_smile:

In terms of software versions, is there any advantage in starting from a fresh image or is it good enough to run an apt-update && apt-upgrade, as the syncosync package is kept up-to-date automatically anyway.

All the best,
Tim

2

Ok, I have been trying the following, with some success. Maybe it’s useful for someone else. Also, not sure if this is a dependable solution and would appreciate some feedback.

First, I copied the contents of my 4.5 TB HDD to a new 16 TB HDD (on another Linux system, not the syncosync box):

dd if=/dev/sdX of=/dev/sdY bs=1M status=progress

The syncosync box will then recognize this just as it did the original 4.5 TB HDD. Now I need to make syncosync use the full space. There might be commands in syncosync’s drivemanager.py to do that, but I could not easily figure out how. So I went with the following steps, logged in as sosadmin on the console, and all commands with sudo:

First extend the physical volume to the full size of the new disk:

pvresize /dev/sda

I wanted to give all extra space to the local logical volume. So find out the name of the local logical volume using:

lvdisplay

The local volume will have a path like “/dev/sos-xxxxx/local”. Then next resize that to maximum possible size:

lvextend -l +100%FREE /dev/sos-xxxx/local

This worked, the new logical volume was extended, and also drivemanager.py confirms the new size when calling it with option --get. However, in the GUI wrong sizes and partition percentages are displayed.

I thus used drivemanager.py to “resize” the local and remote volumes to the sizes that drivemanager.py -g already reports under the field “lv_size”:

sudo drivemanager.py -r '{ "local":"3455463", "remote":"356948"}'

That seems to have set everything consistently within syncosync. Now the GUI reports the full available size. Only the partitioning dialogue still reports a total disk size of 4.3 TB. But I hope I can just ignore that as long as I do not need to repartition.

I will do the corresponding steps on the buddy box and hope that then everything will be working fine. Unfortunately, it seems that development on syncosync stopped, but as long as Debian bullseye still gets security updates, it should be safe to use, I guess.

3

One more thing, lvdisplay now reports that the local logical volume consists of 2 segments. That makes sense, I guess the extra space was added after the space occupied by the remote logical volume. I guess repartitioning through the web interface is a no-go afterwards. (Low-level resizing similar to what I did here should probably be fine.) But I am not expecting to do that anyway. So if you want to follow this procedure and do want to repartition, I guess you should do it before you start the copying of the old HDD to the new one.

4

Just to confirm that things are working fine. I did have to remove the quota for my user account from the command-line using quotaed, though, as changing it in the syncosync web interface to some percentage did not work properly (it seemed to calculate still from the original size).