[dropped] Migration: change application details in backup to avoid duplicate apps

Hi all,

TL;DR: I am trying to (partly) ‘merge’ multiple Yunohosts into one. I intended to backup eg Nextcloud on one server, and restore it on the other that already has Nextcloud. It doesn’t work, because the application already exists. Can I change the backup-info.json, to have the application restore differntly?

Longer version
This is the error on the target server:

root@online:~# yunohost backup restore 20211005-210844
Error: The following apps can't be restored because they are already installed: ffsync, nextcloud

I have a couple of similarly configured Yunohosts, but due to changes at the ISP, I can not run all of them at home easily anymore. One of them is to receive Nextcloud from all the others (it takes too much data for an affordable VPS).

In another thead, @charly suggests using a VPN for my description of the situation, but I realized I should be able to have multiple Nextclouds one the one remaining homeserver and keep things less complicated.

For the moment I am not looking at merging the Nextclouds into one instance.

My question now is: can I change the backup.info.json file to trick Yunohost into restoring the backup to eg nextcloud__2 (and __3, etc), so that they all keep working?

Any thoughts?

What you try to do is a difficult operation…

I think you need at least to change nextcloud by nextcloud__2 in several places in the archive…

  • backup-info.json
  • backup.csv (could contain some path with “nextcloud” (conf php, nginx, logrotate, fail2ban…)
  • *.sql (i am pretty sure it contains a reference to the database name “nextcloud”)
  • settings.yml file (probably contain reference to the id)
  • all config file path need to be moved in the archive like in backup.csv (conf php, nginx, logrotate, fail2ban, data dir…). However, it’s possible that just changing one of the 2 column of the backup.csv is enough…
  • Maybe the nextcloud config itself

It’s a dangereous operation cause you can delete accidentally data (db or files) from the first nextcloud if you don’t do things correctly.

However, if you succeed, a good doc of your manipulation could be a first step to support this feature in core.

The other way could be to install 3 nextcloud and next import manually data with rsync and database… Be sure to be on the same version of nextcloud…

Ai, too bad, but a bit what I was afraid (and more).

In my specific case, it might be easier to install as many Nextclouds as necessary on the decomissioned server, so that the application suffix matches what it should become on the running server, copy files and row data, backup and restore.

In case I try to burn my fingers on the backup-migration-functionality, is there a framework to fall back on, or is it specific string search-and-replace for each application? Vain hope, but I mean, if it works, and can be integrated into Yunohost proper, would it need rework for each application, or should there be some variables so that it also works for other apps?

TL;DR: taking a shortcut doesn’t work without certificates; experimenting with backups has little guarantee of ‘no configuration errors’ even if things seem to work: no go at this moment.

The way of least resistance seemed:

  • homeserver1
    • will stay online at home
    • has app ‘nextcloud’
  • homeserver2
    • migrate mostly to VPS2, except nextcloud
    • has app ‘nextcloud’
    • install new ‘nextcloud__2’
    • copy database records from nextcloud to nextcloud__2
    • make backup
    • restore at homeserver1 as nextcloud__2

Before that I wanted to log in to the Nextcloud webinterface on homeserver2, to get some feeling of what will be migrated and the complexity and whether I could do without some of the metadata.

I did not get to that: I don’t manage to get a valid certificate on homeserver2.

  • added the same subdomains to homeserver2 and VPS2
  • copied cert.pem and key.pem over from VPS2 to homeserver2 for the nextcloud-subdomain
  • found that the certificate chain is broken
  • found that this workaround is taking the long way home (along with enabling/disabling the subdomains in my hosts file it gets tired quickly for little gain)

The useful way seemed looking into the locations you mentioned, to get some script to change values where needed to be able to restore under another name. That is too risky and time consuming at the moment. The Yunohosts don’t run ‘critical’ infrastructure, but still do mail, backups, chats etc for family and friends.
By coincidence my daughter wiped her phone last week, just now her Nextcloud has been offline for a few weeks. In order not to repeat such a scenario, first thing is to get their services up as soon as possible.
Maybe I’d be faster in the end with a script (after a number of servers/backups), but Nextcloud is too complex as a starter for experimenting. I’m afraid to get a seemingly running, but actually raining Nextcloud.

So for this thread I thank you for taking time to read my problem and help with your suggestions, but will look for another solution. (Probably via VPN, I’ll post back if I have it running before the thread closes.)