Change the hard drive in ncp

I want to change my old hard drive which is too small for a bigger one.
Do you please know how to do this without having to reinstall ncp?
Thank you very much

I have a raspberry 4 with the latest version of ncp and nextcloud

Can you share output of ncp-report via a pastebin service?
You would have to clone data from the old drive to the new one.
I’ve used clonezilla (livecd/usb) for that, but if on Linux can use dd or rsync.
Depending on how you set up, if you get newly cloned drive mounted at same mountpoint the old one used, system should be fine, just run nc-scan to make sure.

Back up your system before you start, so you can restore if things turn bad.

If you have btrfs as filesystem, which i assume with ncp, you can use btrfs tools to move the volume from one drive to the other quite easily i did so a whoile ago

Here is how i did it:

you dont need to format anything and during the replace process the filesystem is fully accessible.

sudo bash

will open bash as su

btrfs filesystem show 

will list you the current filesystem, you will need the deviceid.

btrfs replace start 1 /dev/sdb /media/myCloudDrive/ -f

this moves the complete content of the old drive (1) to the new device (sdb), /media/myCloudDrive/ is the mountpoint of the filesystem, -f means to force overwrite any content on the target drive.


btrfs replace status

you can get the progress, the operation will take a while and after that a

btrfs filesystem resize myCloudDrive max

will expand the filesystem onto the full drive

You can now disconnect the old drive and be happy. Be aware that the replace process will, depending on the ammount of data in the old drive, take several hours…

1 Like

Btw, i did that on a pi2b back then, i guess the pi4 is significantly faster due to usb 3.0

Thank you very much for your information,
I will probably make the first manipulation it seems more reliable to me not to lose data.

Btrfs replace is a very safe operation, the filesystem on the original drive will stay there as long as the operation is innprogress, you can even reboot during the process and the operation will continue where it stopped. At the end of the operation the new drive takes over and the btrfs superblocks of the original drive will get deleted.

all right, thank you very much for the information

I did a cloning with balenaetcher
everything works perfectly

do you know if I can partition my new disk?


I just did this. Worked like a charm, thanks a bunch! Unfortunately i’m running into some trouble trying to resize the filesystem.
lsblk tells me that the partition is large enough:

sda 8:0 0 465.8G 0 disk
└─sda1 8:1 0 465.7G 0 part /media/myCloudDrive

meanwhile filesystem show only gives me:

Label: ‘myCloudDrive’
Total devices 1 FS bytes used 215.65GiB
devid 1 size 223.57GiB used 220.07GiB path /dev/sda1

So far, so good. Unfortunately the resize command doesn’t work:

root@nextcloudpi:~# btrfs filesystem resize myCloudDrive max
ERROR: resize: cannot stat max: No such file or directory

What did I miss?

Hope this thread is still active,

help would be much appreciated, as i’m not too good with Linux and have run out of ideas…

Problem solved. Turns out, it hat issues with the command, then accepted

btrfs filesystem resize max myCloudDrive

to get the whole thing actually working, I mounted the drive in a Mint VM and did it from there (used the path, not only the label, that didn’t work nevertheless) Worked like a charm all of a sudden.

Hi @FadeFx
I have a question on this operation:
I’m using a Odroid HC1 (one sata-port , one usb2.0 port). The small ssd is on sata, the new one is on usb-to-sata adapter.
Does your way work, if I afterwards remove old ssd and move new ssd from usb to sata?
I’m asking this question, because with cloning by dd command this did not work.
(my way was: activate maintenance mode, clone small to big ssd by dd command, shutdown and move big ssd to sata port, restart system. then some checks are fail).

that depends, if the mountpoint of the drive (sda or sdb or whatever it is) changes, this could cause the volume to be unmountable, but this should be fixable somehow. I would have to do some research myselfs on how to fix it, but i am pretty sure it can be done. Actually most likely the same way could fix your current issue i guess

I don’t really believe in your mountpoint theory, because I checked mountpoints and drives with lsblk:
using only small ssd on sata it is “sda”.
Using small ssd (sata) + big ssd (usb) during dd-command it was: big ssd = sda, small ssd = sdb
then using only big sdd on sata it is “sda” again.
So in productive configuration it was always “sda”.
Let’s see what else I can try.

I’m not sure what is more work:
Do I put my time into replacing the hard drive or do I build a new instance + restore config, but then may have to reset or do some maintenance all of my family’s devices or even lose data.
This is the problem of a family administrator :slight_smile:

Thats what i meant, you move the volume from sda to sdb, then you unplug both drives and reconnect sdb as sda, but the volume expects sdb now. However, give it a try, worst thing to happen would be you have to keep the old drive connected until yo find out how to fix it.

Have now tried all variations that came into my mind:

  • copying with dd from sda to sdb from working cloud
  • copying with dd from sdb to sda from working cloud
  • then connecting both or just one drive to sata or to usb

It turns out, that my cloud is only working when the old ssd is connected to sata. Nothing else.
In all other cases I get
nextcloud check = fail
MariaDB service = down
HPB service = down
So for the moment I ran out of options.