Migrating RPi to Rock64 for idiots

ā„¹ļø Support šŸ“¦ Appliances (Docker, Snappy, VM, NCP, AIO)
1

Iā€™m (one of) the idiot(s) in question. Possibly mostly because I embedded a nextcloudpi setup as mission critical in our small business. Anyway, Iā€™m looking to migrate it to a Rock64 board, which arrived on the doorstep today.

I have a number of backups of the RPi implementation, complete with data. I only have about 50GB total, so I take a backup like that each week (manually because I canā€™t figure out how to schedule it to run @ 2300 local on a Saturday).

What Iā€™m not sure of is whatā€™s in that backup in terms of config, and what I must do first with the Rock64 before I attempt to restore a backup onto it? Iā€™d be most grateful if anyone could set me straight on these.

IP address. My router keeps 192.168.1.6 for the RPi. Is the backup aware of this and does it need the new machine to also have this IP? Provided I update my port forwarding appropriately, can I keep the Pi up until the R64 is good to go, then ā€˜flick the switchā€™ such that the traffic hits 1.7 (for example) instead of 1.6?

Swapfile, database & datadir. These are all on the same physical USB 3 external drive, and Iā€™m pretty sure I remember correctly in that it has separate partitions for them as swap, ext4 and btrfs respectively. Will restoring a backup do all or any of this for me? I realise this is more OS level stuff, but Iā€™m quite the novice with linux. Is simply pulling this disk from the RPi setup and hanging it on the R64 far too ambitious?

Security. Iā€™m sure my user accounts etc are all in the backup, but does it also hang on to its certificates and various security settings as may exist?

Are there questions Iā€™m not asking that I should, and has anyone seen a ā€˜migrating your nextcloud from RPi to R64 explained for eight year oldsā€™ post anywhere?

Thanks for taking the time to read.

2

So fifty people read this, and no-oneā€™s prepared to offer any kind of input. Does this mean that fifty other people want to know how this is done?

3

youā€™re welcome.

and maybe you want to search the forum first next time? as there are several hints about thisā€¦

it seems so. and yes. things like this might happen.

4

Well I would contend the answer is in fact not to be found by searching, or I wouldnā€™t waste my time asking. Given the stated aim of the NCP project to be ā€˜easy for non-technical usersā€™ or words to that effect, this is quite surprisingly the least helpful forum Iā€™ve used, and by some margin. It up against pretty stiff competition for that coveted title too.

5

so what do you expect after your postings?

the first one showing a full disrespect of searching the forum - because i, myself, do remember having read of how to migrate from rpi to rock64 in this forum before.

and all following postings being rude?

iā€™m out of here. sorry.

6

shush Jimmy. If youā€™ve nothing to add, best to add nothing.

7

How do you perform backups? Do you follow this guide?
https://docs.nextcloud.com/server/16/admin_manual/maintenance/backup.html

8

Is the backup aware of this and does it need the new machine to also have this IP? Provided I update my port forwarding appropriately, can I keep the Pi up until the R64 is good to go, then ā€˜flick the switchā€™ such that the traffic hits 1.7 (for example) instead of 1.6?

Nextcloud does not know or care about the IP. It will have no effect on the backup. The router may assign a new IP for the Rock64, or you could set the 192.168.1.7 IP as an assigned IP for your Rock64. You would do that in the router admin page using the MAC address of your Rock64.

Will restoring a backup do all or any of this for me? I realise this is more OS level stuff, but Iā€™m quite the novice with linux. Is simply pulling this disk from the RPi setup and hanging it on the R64 far too ambitious?

You should not worry about OS level stuff. You should probably use a prebuilt image with nextcloud on it for your Rock64. For example one from OwnYourBIts: https://ownyourbits.com/downloads/
Back up your nextcloud data/files and database normally using rsync and transfer it to the new Rock64 setup. You can find this info in the Admin manual for your nextcloud version, which should be the latest version. Follow the link from @Gee858eeG.

Security. Iā€™m sure my user accounts etc are all in the backup, but does it also hang on to its certificates and various security settings as may exist?

You can just get a new certificate from LetsEncrypt for your new board/domain. I would suggest backing up your RPi but keep it in serviceā€¦ set up your Rock64 and transfer everything to it, set the new Rock64 up on a new domain with new certs and once everything is up and running smoothly on Rock64, only then think about decommissioning the RPi.

Good luck!

1 Like
9

Iā€™ve just been using the backup script from the admin interface, limit set to four. It generates a single .tar file of about 50GB on the local disk of the RPi NC system, which I then copy off to my windows machine using WinSCP. Itā€™s manual, and I try to do so weekly. Itā€™s pretty slow, so Iā€™m sure I need to move to an rsync backup strategy and intend to cross this bridge once Iā€™ve managed to get the R64 up.

10

@Cabana - big thanks.

OK cool, thanks. Understand how to set it.

Yes, Iā€™ve managed to deploy that image to the R64. Whatā€™s causing me pain currently is the mounting of my USB disk. Iā€™ve made four partitions and formatted them swap, EXT4 and BTRFS x2 respectively:

pi@rock64:~$ sudo fdisk -l | grep sda
Disk /dev/sda: 1.8 TiB, 2000365289472 bytes, 3906963456 sectors
/dev/sda1        2048   58595327   58593280    28G Linux filesystem
/dev/sda2    58597376  253911039  195313664  93.1G Linux filesystem
/dev/sda3   253911040 2080079871 1826168832 870.8G Linux filesystem
/dev/sda4  2080079872 3906250751 1826170880 870.8G Linux filesystem

I wanted to use these for swap, database, datadir and backup respectively. So I mkswap-ed /dev/sda1 which seemed to work, and I created /media/USBdisk/ and under that ncdb_mount, nc_datadir_mount and nc_backup_mount.
Then I went to mount my partitions thusly:

sudo mount /dev/sda3 /media/USBdisk/nc_datadir_mount

which seemed to work:

df | grep sda3
/dev/sda3      913084416   16896 910969600   1% /media/USBdisk/nc_datadir_mount

so I did others similarly and chown-ed them so they were similar to the RPi setup:

ls -l
drwxr-xr-x 1 www-data www-data    0 May 22 13:08 nc_datadir_mount

and then added lines to the /etc/fstab like

/dev/sda3 /media/USBdisk/nc_datadir_mount btrfs defaults 0 0

I rebooted here, headed for the admin interface and asked Nextcloud to shift the datadir into this path using the script, and it tells me it doesnā€™t exist, which of course isnā€™t true. I checked nonetheless and sure as eggs is eggs it is there. Thing is, /media/blahblahblah_usb_disk_identifier_string/ is also there, and this now has a nc_datadir_mount in it
Iā€™m stuck at this part and could really use some help on mounting the partitions correctly please.
Many thanks in advance.

11

I think that maybe I was having trouble with automount competing with my fstab mounting instructions, so I flashed my image again, reformatted the USB drive partitions and re-did the mounting, and again the move DB and move datadir scripts failed and resulted in a broken instance.

Started again from scratch, and this time followed this guide

1. sudo -u www-data php /path/to/nextcloud/occ maintenance:mode --on
2. mkdir -p /new/path/to/data
3. cp -a /path/to/data/. /new/path/to/data
4. chown -R www-data:www-data /new/path/to/data
5. nano /path/to/nextcloud/config/config.php
       'datadirectory' => '/new/path/to/data',
6. mysqldump -u<rootuser> -p > /path/to/dbdump/dump.sql
7. Adjust "oc_storages"database table to reflect the new data folder location:
      mysql -u<rootuser> -p
      //enter mysql root password, then within mysql console:
      use <nextclouddb>;
      update oc_storages set id='local::/new/path/to/data/' where id='local::/path/to/data/'; //take care about backslash at the end of path!!
      quit;
8. sudo -u www-data php /path/to/nextcloud/occ maintenance:mode --off

to move my datadir, all good. The I used the ncp-config script to move the db, and that too went well.

So then I scpā€™d the most recent backup over from the pi and dropped that in my backup partition on the R64, pointed the restore script at it and crossed my fingers.

[ nc-restore ]
check free space...
extracting backup file /media/ncbackup_mount/nextcloud-bkp_20190608_1559962582.tar...
restore files...
restore database...
restore datadir to /media/USBdrive/ncdata...

Bastard. /media/USBdrive/ncdata is the datadir of the RPi instance. The R64 is /media/ncdata_mount.

The script forged ahead anyway, made a folder called USBdrive/ncdata on the 8GB uSD card, filled it up and crashed the system.

Start again. This time Iā€™ll make my mount point names match the RPi instance

12

Aargh.
OK, so having set it up with matching mount points I once again tried to restore:

nc-restore
check free space...
extracting backup file /media/USBdrive/ncp-backups/nextcloud-bkp_20190608_1559962582.tar...
restore files...
restore database...
backing up existing /media/USBdrive/ncdata to /media/USBdrive/ncdata-06-08-19...
mv: cannot move '/media/USBdrive/ncdata' to '/media/USBdrive/ncdata-06-08-19': Device or resource busy
Cleanup

:frowning:

13

Your fstab entry:

Your backup procedure:

Your hdd is mounted on /media/USBdisk/nc_datadir where it should be actually just mounted to /media/USBdisk. So your backup seems to be placed on the root of the hdd if I understand correctly (I donā€™t use ncp, so I donā€™t actually know how it backs up data). The backup procedure of your ncp tries to move data from your mount point of your hdd which (again) is /media/USBdisk/nc_datadir to a new directory outside of your hdd. That means it tries to move your mount point, which of course it isnā€™t be allowed to do.

If you mount the hdd onto /media/USBdisk your backup procedure might just workā€¦ As I said, I donā€™t really know the backup procedure of ncp. Maybe you will have to create a folder nc_datadir within that drive and move your existing backup from the root of the hdd to that folder. But someone else should know better.

14

Got you. I think Iā€™d just about arrived at that conclusion myself, but thanks. Iā€™m being tripped over by a piece of code that I actually donā€™t need, and I suspect I could modify with cp rather than mv and itā€™ll do whatā€™s needed. That said, I donā€™t want a backup of the default state, so Iā€™m going to try to work through the restore script and adapt it to discard the existing rather than back it up using mv.