Reuse external disk with dietpi_userdata on a new machine

[fhals]

Hi all,

I basically configured a new dietpi machine with the same software packages as the old one.

Machine_old uses an external disk for dietpi_userdata.
Ideally, I’d like to mount the external disk on machine_new and tell it to use the external dietpi_userdata.

It seems like the drive-manager will overwrite the userdata-folder on the external drive, so this is no option.
Is there a good practice to make it just use the former external userdata as a replacement?

Thanks for any ideas
Frans

[Jappe]

Mount it and symlink /mnt/dietpi_userdata to the external drive.

Or just overwrite it, if you have a backup and you’re sure it’s exactly the same.

[fhals]

Thank you for your ideas.
Unfortunately, both don’t seem to be perfect.
Option1 may be critical when using the drive manager to move the data elsewhere one day.
It also breaks the concept of being update-savy through the use of dietpi controls only.
Option2 doesn’t reuse the external drive/folder which is the goal I like to achieve.

Quick and dirty: One could edit the dietpi configuration file and point the userdate to the external drive and reboot?

Long way is based on your idea no. 2.
Stop all services.
Overwrite local userdata with external userdata.
Reboot.
If all is fine, use the drive manager to relocate it to external again.

Does anybody knows, where dietpi stores the current userdata location?

[Jappe]

@fhals

Does anybody knows, where dietpi stores the current userdata location?

dietpi-drive_manager

# Obtain actual user data location on disk (follow symlinks)
		FP_USERDATA_CURRENT=$(readlink -f /mnt/dietpi_userdata)

and
dietpi-gobals

G_CHECK_USERDATA(){

		local return_value=0 fp_actual='/mnt/dietpi_userdata'

		# Symlinked?
		if [[ -L '/mnt/dietpi_userdata' ]]
		then
			# Check physical location exists (is mounted)
			fp_actual=$(readlink -f /mnt/dietpi_userdata)
			[[ -d $fp_actual ]] || return_value=1
		fi

		G_DIETPI-NOTIFY "$return_value" "DietPi-Userdata validation: $fp_actual"
		(( $return_value )) || return 0

		G_WHIP_MSG "[FAILED] DietPi-Userdata validation\n\nDietPi was unable to verify the existence of the userdata directory ($fp_actual).\n\nPlease ensure all previous external drives are connected and functional, before trying again.\n\nUnable to continue, exiting."
		kill -INT $$ # kill all current scripts, excluding shell
		return "$return_v

But if you change it there it will maybe overridden on an update.

There is also noted, that it follows symlinks, so mounting the external drive and linking it to this path seems a legit solution IMO.

[Joulinar]

Don’t do it that complicated.

Drive manager is doing nothing else than,

• stop all services
• copy your data
• create a sym link

Basically you can do same, just without moving date

• stop services
• move current user data within /mnt to a temp location
• create sym link pointing to user data on your external drive

[fhals]

Thanks to both of you.
Lazy guys migration doesn’t work
dietpi-sync from the external userdata folder to internal one, followed by restart, works fine but gives back errors and malfunction when using nextcloud, jellyfin etc.
As this consumes more time to fix than a service to service migration/reconfiguration, I will stick with a new setup and import.

[Joulinar]

Why not simply creating the sym link? This would be a task done in seconds

However, you have forgotten to tell us that you are using Nextcloud. Of course, further configuration is required as you need to set the database access again. The old database has a different password than what is configured on your new nextcloud. But that’s nothing that can’t be fixed in a matter of seconds. Much faster than a new installation.

[fhals]

Thank you for your patience.
I will retry with a symlink as Jappe altready suggested.
Joulinar: Setting up Nextcloud after a mint installation with similar admin credentials will be sufficient prior symlinking?

[Joulinar]

it’s not about the admin account to login into NC. It’s the database password that has been specified within NC configuration file. It’s a random password stored within /var/www/nextcloud/config/config.php

If you have access to the old system still, you can copy configuration. If not, we would need to set a new database password.

[fhals]

Of course! I forgot the /var/www
I still have access and will try as suggested.

[Joulinar]

another option for NC system migration, we have an undocumented script, that could be used on source side to create a full backup DietPi/.meta/dietpi-cloud-migration at b9bebf642bf2a4bc21532dbe8c4b64409a365b93 · MichaIng/DietPi · GitHub

On target system you would need to connect external HDD (and sym link user data) before doing the reinstallation of NC. This way our install script could pick the backup created before.

[fhals]

Thank you for encouraging me to use the short path.
There have been some difficulties with the database access, needed to fix some user/group settings.
Especially Jellyfin has been in trouble and needed a reinstall.
Glad to have my Nextcloud with all the apps and users without hustle.
I will keep the backup-script for the next time.
Thank you Jappe and Joulinar!