Move a Lino site to a new server¶

This document explains the following situation: you have a running production site on a server S1 and you want to move that site to a new server S2. You have installed S2 as described in Set up a Lino production server, so you have the same application running on both servers, maybe a newer version on S2. S1 has confidential production data while S2 has fictive demo data. You now want to copy the data from S1 to S2, migrating it on the fly as needed.

Procedure¶

Create a snapshot with the special name snapshot2new on the old production site:
```
$ go prod
$ python manage.py dump2py -o snapshot2new
```
The -o option is not needed the first time, but you are likely to run this procedure several times (see General workflow below).
Create the file restore2new.py, which initially is just a copy of the restore.py created by the make_snapshot.sh:
```
$ cd snapshot2new
$ cp restore.py restore2new.py
```
You might need to edit this file e.g. if the new server has a newer version of the application. And you don’t want these edits to get overwritten in case you need to run the procedure again.
Create a file initdb_old2new.sh in the project root of the future production server. Adapt it as needed:
- set OLD to user@S1:/path/to/prod/on/old/server
- set NEW to /path/to/prod/on/new/server
Run the script. This will first copy all relevant data from S1 to S2 using rsync, then replace all data in the database on the new site with the data that has been copied from the old production site.
The restore.py (second part of your initdb_old2new.sh script) might give error messages e.g. when S2 has a newer version of the application and no migrators have been defined by the application developer.

In that case you should ask support of the application developer because it’s their job to specify the details of what happens during the data migration. When you get instructions to manually edit the restore2new.py file, then keep in mind that you must –of course– edit this file on the old server, as it will be mirrored to the new server.
Restart the Lino services on the new server and check whether it now has a copy of the production data. Take care to check whether uploaded files (lino.modlib.uploads) have been copied and are available on S1.

General workflow¶

When your manual tests pass, you inform the site operator that it’s now their turn to test the new server. There are chances that they will find more problems.

After fixing the problems, you can simply run the procedure again (create a snapshot2new on S1 and then run initdb_old2new.sh on S2). When no more problems are detected and the site operator decided to actually move, you will run it a last time to synchronize their latest data before stopping the old production server.

Files¶

initdb_old2new.sh¶

This is a variant of the initdb_from_prod.sh script without the first part. It syncs and then restores a snapshot from an “old” site to a “new” site. Here is our suggested template for this file:

#!/bin/bash
# Copyright 2016-2026 Rumma & Ko Ltd
# initialize this project latest production snapshot

set -e

# OLD=/usr/local/django/prod
OLD=joe@S1:/usr/local/lino/old
NEW=/usr/local/lino/new

logger -s initdb_old2new.sh was started

logger -s PART1 : MIRROR MEDIA FILES AND SNAPSHOT
OPTS="-a --verbose --delete --delete-excluded --delete-during --times --omit-dir-times"

function doit {
    nice rsync $OPTS $OLD/$1 $NEW/
}

doit media
doit snapshot2new


logger -s PART2 : RESTORE SNAPSHOT TO $NEW
cd $NEW
. env/bin/activate
python manage.py run snapshot2new/restore2new.py --noinput
python manage.py buildcache -b

logger -s initdb_old2new.sh finished