Guide: Migrating to a bigger and better SSD

rabidsloth · 25 May 2022 06:11

With the merge looming ahead, depreciation of the fallback client options, and general fatigue with regular pruning, I decided to migrate my chain data from a 1TB to 2TB SSD (installed on the same device.) I’ve seen multiple people asking for a guide on how to do this in the RP discord, so wrote up the steps I took. I’d appreciate any feedback from the seasoned Devs here to make improvements to the draft and we can hopefully get some manifestation of this uploaded to the Rocketpool Docs.

At a certain point, Rocketpool node operators using a 1TB SSD will need to upgrade to a 2TB SSD (or larger) even if regularly pruning. You can follow these steps to migrate your docker containers to a secondary SSD mounted locally, without re-syncing the the entire blockchain from scratch.

Stop rocketpool to shut down the docker containers:

`rocketpool service stop`

Then check for the docker root directory field by pulling up general docker information:

`docker info`

The default for an Ubuntu installation is var/lib/docker. Now that you know where to copy the docker volumes from, docker can be fully shut down:

`sudo systemctl stop docker`

Follow the rocketpool guide for mounting and formatting your new drive in the Rocketpool docs. Make sure to take note of the drive path you’ve chosen for the new drive (e.g. mnt/rpdata)

Now you can run rsync to copy your existing docker containers to the new drive:

`rsync -avxP <docker root directory>  <new drive path>`

It should look something like this:

rsync -avxP var/lib/docker mnt/rpdata

Note: rsync is included by default by most linux distributions, but if you do not have it for whatever reason, you can install it with the command:

`sudo apt install rsync`

The file transfer will take some time depending on read/write speeds. Once it is completed, follow the rocketpool guide for creating a .json file pointing docker to your new mount point:

Now start up docker to reload the system deamon:

`systemctl start docker`

It’s a good idea at this point to make sure that the docker images are now referencing the new mount point. Run the command:

`docker images`

Now check for an image id entry corresponding to a rocketpool docker repository (any of them should work) and use the following command to check its file location:

`docker inspect  <image_id> | grep WorkDir`

The returned “WorkDir” path should start with your new drive’s mount point (e.g. “/mnt/rpdata/docker/…”) At this point, you can restart the Rocketpool service:

`rocketpool service start`

Keep an eye on your validator and make sure that it starts attesting as usual. If you had Grafana set up previously, it should automatically start reflecting the new drive’s storage space. Congratulations on all that fresh silicon!

highflyer.eth · 25 May 2022 20:46

I was facing the same problem. For me the easiest solution was using Clonezilla. (https://clonezilla.org/)

Clonezilla can be downloaded as ISO image, which is used to create a bootable USB stick. The node can then be cloned as follows:

Clonezilla Live Doc
Boot the node system (I have a NUC) using the bootable USB stick. You can boot to RAM so that the USB stick can be removed, which frees up a USB port (if necessary)
I attached the new SSD using a cheap USB adapter (NVME M.2 to USB-C)
Follow the Clonezilla instructions and carefully select source and destination disks. It is important to use “Expert Mode” and set option -k1. This expands all partitions proportionally to the new disk size.
In my case the clone process took about 45 minutes. Thereafter, you shutdown the NUC, switch SSDs and start up the system. The new SSD is an exact copy with larger disk size. It should just continue validating.

I followed this route as it is absolutely fail safe. There is no need to set up the operating system on the new SSD. As the NUC is booted from the USB stick, the regular operating system incl. all services is inactive and can safely be cloned. All existing settings are preserved. In case the clone process fails, I can just keep validating with the existing SSD.

I have to add that I run my node in native mode without the docker containers. My NUC only has one NVME M.2 slot so that I couldn’t just add a second SSD.

Please absolutely make sure to not boot again from the old SSD as this can cause a slashing event, in case there are two validators running in parallel using the same set of keys. I explicitly wiped my old SSD using safe erase.

0xb0a7 · 31 May 2023 23:43

I’m wondering about using rsync to copy the images to the second SSD…
Is there some slashing risk in leaving the original copy of the images around if they somehow became activated in the future after the new SSD has been used for awhile? What is the significance of using rsync as opposed to mv to move the files?

fraz · 7 March 2024 22:23

adding the link for a helpful guide written by Remy Roy also

github.com

eth-educators/ethstaker-guides/blob/main/migrating-to-a-larger-disk.md

# Guide on How to Migrate to a Larger Disk for an Ethereum Validator

Disk usage is a constant concern for stakers and node operators. The blockchain data keeps growing each day with new transactions and states to store. Stakers and node operators are mainly those responsible for storing this data. During the life of a staker or a node operator, it is likely that you will need more space for this concern. Migrating to a larger disk might become the last solution for some.

This guide is meant for people with little or no experience migrating to a larger disk. It will show you step by step how to check your disk usage, which solutions are possible to manage disk usage, which tools you will need to migrate to a larger disk, and the process of migrating to a larger disk. It will assume you are using a modern Linux distribution to run your staker or node operating system. Many of these instructions and steps are possible on Windows or macOS, but this is out of scope for this guide.

A video tutorial of this guide can be seen on https://youtu.be/xWyf84Syq7o .

If you know what you are doing, you can simply read the [Migrating to a Larger Disk](#migrating-to-a-larger-disk) section.

## Current Expected Disk Usage

On Mainnet, you should expect the current disk usage to be around **1 TB to 1.7 TB**, depending on which client and configuration you are using, excluding archive nodes. This should be accurate as of today, January 2024. It might be possible to still use a 1 TB disk in some extremely specific scenarios, but any serious staker or node operator should be using a good 2+ TB SSD. If you are building a new machine, you should consider buying or starting with a good 4 TB SSD to avoid having to perform this kind of maintenance in the short or medium term.

## Solutions to Check Before Buying a New Disk and Migrating

### Checking Your Current Disk Usage

On Linux, you can run `df -h` to find out more about filesystem disk usage. It will return something like this:

This file has been truncated. show original

sourced from ethstaker

killjoy · 18 March 2024 19:50

Great guide. Mostly followed it. I noticed that although I selected the -k1 option in clonezilla my partition / filesystem still was stuck at the size of the original disk.

I used GParted to allocate the unused space, and then followed the instructions in this thread to expand the logical volume and file system.