Migrating System to New Spindle

V

von Corax

I have a box with two disk spindles. One holds `/`, `/tmp`, and `/usr`, and the other holds `/var`. Both spindles are beginning to fail, so I want to migrate them to a new disk. I have installed a base system on the new (much larger) spindle, and would now like to copy the system from the old spindles to the new, but I'm suffering a headgap on how to proceed. (I think I have done this before, but I moved recently and have mislaid my notes.)

The old system uses UFS, and the new system uses ZFS (although I am willing to reformat the new system to UFS if that would make things easier.)

Can anyone guide me through the steps to accomplish what I want to do?
 
Okay. Still, I'm suffering a crisis of confidence here; any pointers on what I must/should/should not/must not copy to the new system?
 
How much data and services are we talking about? And is anything mission critical or just home server setup? And you have two hardware systems online at the same time right?
 
Homelab server, nothing mission-critical except my PostgreSQL and Gitea servers. And yes, I have both the old and new spindles plugged in, and am able to boot either the new system or the old.
 
Boot the old system, and do a pkg prime-list, that'll give you a list of packages you installed (without their dependencies). Boot the new system and install that list. Then you can simply copy the things you need (data, configuration files) from the old disks.
 
I'd replace `pkg prime-list` with `pkg prime-origins` as it has the category; not many conflicts there but some conflicts do exist. prime-list tracks flavors while prime-origins loses those in case one or the other is more desired.

UFS's dump only reads UFS but restore doesn't care about the filesystem. Changing partition counts requires copying data in/out accordingly. If I recall, ZFS's send/recv require ZFS be present on both ends of the transfer. Otherwise you can use other tools like tar, rsync, etc. but such tools have less of an understanding of the filesystem so would come with side effects.

If your new disk is large enough to only partition half of it to hold all of the data, you can have both ufs and zfs partitions so you could do dump/restore to initially migrate and then transfer it to the other filesystem on the other partition later. This has an advantage of always being able to redo the filesystem by transferring a current copy from one partition to the other and then changing boot and mount points to only use the new copy which is all doable withotu a second disk. 1 disk doing both the read+write of a transfer is slower than a second disk and 2 copies on 1 disk is the least reliable backup plan. For magnetic it keeps data to a faster part of the disk for one partiotn while keeping it at a slower part for the second partition. You can always resize the first partition to take up the second partition when you need more space but that only works if it is only 2 partitons; though usually minor, there can be side effects of resize operations on the filesystem.

If the disks are failing and you do not have a backup, you should focus on copying the most critical/custom data to the least critical/custom. Some disk failures may be best worked around by not doing random seeks but instead reading sequentially like dd and similar tools can perform.

Keeping all of the data is fine if you can read the disks, but only keeping your custom data may help clean up the install of any older debris/corruption. If you have the space, you could transfer everything to a backup file or partition on the new drive so if you are missing anything then you still have it in reach.
 
You must log in or register to reply here.
Back
Top