# Migrate instance **URL:** \ **Category:** Administrators\ **Created:** [March 11, 2018, 10:28am UTC](https://talk.getindico.io/t/migrate-instance/256 "2018-03-11T10:28:35Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![mtorrisi](https://talk.getindico.io/user_avatar/talk.getindico.io/mtorrisi/32/47_2.png) [@mtorrisi](https://talk.getindico.io/u/mtorrisi)\ **Post date:** [March 11, 2018, 10:28am UTC](https://talk.getindico.io/t/migrate-instance/256/1 "2018-03-11T10:28:35Z")
Hi everyone, I’ve installed a new Indico 2.0 istance an my organization datacenter, but now I need to move to another one. I’d like to know of there is any way migrate the database, from the old istance to the new one, or I’ve to just dump and restore it. At same how to proceed for the customization I did on the old one. Thanks in advace. ---
**Author:** ![ThiefMaster](https://talk.getindico.io/user_avatar/talk.getindico.io/thiefmaster/32/509_2.png) [@ThiefMaster](https://talk.getindico.io/u/ThiefMaster)\ **Post date:** [March 11, 2018, 10:57am UTC](https://talk.getindico.io/t/migrate-instance/256/2 "2018-03-11T10:57:07Z")
Just reinstall it on the new machine but instead of doing the setup wizard etc., restore a database dump (`pg_restore` / `pg_dump`), copy the config (`/opt/indico/etc`) and materials/attachments (`/opt/indico/archive`, possibly the legacy archive folder as well if you migrated from 1.2). Regarding customizations, if you used the `CUSTOMIZATION_DIR`, simply copy that folder as well. If you modified the code/templates directly inside the virtualenv… well, let’s hope you didn’t 😉 ---
**Author:** ![mtorrisi](https://talk.getindico.io/user_avatar/talk.getindico.io/mtorrisi/32/47_2.png) [@mtorrisi](https://talk.getindico.io/u/mtorrisi)\ **Post date:** [March 11, 2018, 11:10am UTC](https://talk.getindico.io/t/migrate-instance/256/3 "2018-03-11T11:10:16Z")
Thanks for the answer @ThiefMaster, but > [@ThiefMaster](#): > > Just reinstall it on the new machine but instead of doing the setup wizard I already did the setup wizard 😖 damn… What can I do? ---
**Author:** ![ThiefMaster](https://talk.getindico.io/user_avatar/talk.getindico.io/thiefmaster/32/509_2.png) [@ThiefMaster](https://talk.getindico.io/u/ThiefMaster)\ **Post date:** [March 11, 2018, 11:22am UTC](https://talk.getindico.io/t/migrate-instance/256/4 "2018-03-11T11:22:43Z")
No problem, running it doesn’t do any harm (and you actually don’t have to manually create some of the other directories like tmp, cache and assets!). Just restore your database dump now and copy the old config (or compare the two to see if there are any differences) ---
**Author:** ![mtorrisi](https://talk.getindico.io/user_avatar/talk.getindico.io/mtorrisi/32/47_2.png) [@mtorrisi](https://talk.getindico.io/u/mtorrisi)\ **Post date:** [March 11, 2018, 11:24am UTC](https://talk.getindico.io/t/migrate-instance/256/5 "2018-03-11T11:24:09Z")
Ok,tnx again I’ll do it and let you know ---
**Author:** ![mtorrisi](https://talk.getindico.io/user_avatar/talk.getindico.io/mtorrisi/32/47_2.png) [@mtorrisi](https://talk.getindico.io/u/mtorrisi)\ **Post date:** [March 14, 2018, 9:48pm UTC](https://talk.getindico.io/t/migrate-instance/256/6 "2018-03-14T21:48:33Z")
I finally found some time to try to restore the database, but it doesn’t work, following what i did. In the old machine `pg_dump indico > /tmp/indico_db.bak` then i moved in the new one, where I ran: `psql indico < /tmp/indico_db.bak &> file.log` But many errors like `...already exists...` I tried also in the old machine `pg_dump -Fc indico > /tmp/indico.db` In the new machine `pg_restore -v -c -1 -d indico /tmp/indico.db &> file.log` In this last case I get ```auto pg_restore: [archiver (db)] Error from TOC entry 4010; 1259 16891 INDEX ix_affiliations_name_unaccent indico pg_restore: [archiver (db)] could not execute query: ERROR: function unaccent(unknown, text) does not exist LINE 1: SELECT unaccent('unaccent', value) ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts. QUERY: SELECT unaccent('unaccent', value) CONTEXT: PL/pgSQL function indico.indico_unaccent(text) line 3 at RETURN Command was: CREATE INDEX ix_affiliations_name_unaccent ON users.affiliations USING gin (indico.indico_unaccent(lower((name)::text)) publ... ``` Even though the `unaccent` extension should be exist, buecause in the installation process there is `su - postgres -c 'psql indico -c "CREATE EXTENSION unaccent; CREATE EXTENSION pg_trgm;"'` Any hint on that? Thanks in advance. ---
**Author:** ![ThiefMaster](https://talk.getindico.io/user_avatar/talk.getindico.io/thiefmaster/32/509_2.png) [@ThiefMaster](https://talk.getindico.io/u/ThiefMaster)\ **Post date:** [March 14, 2018, 10:02pm UTC](https://talk.getindico.io/t/migrate-instance/256/7 "2018-03-14T22:02:00Z")
Very strange. These are the commands we use all the time and it works fine (on a database that has the two extensions of course): ``` pg_dump indico -Fc -f backup.dump pg_restore -d indico -O backup.dump ``` ---
**Author:** ![mtorrisi](https://talk.getindico.io/user_avatar/talk.getindico.io/mtorrisi/32/47_2.png) [@mtorrisi](https://talk.getindico.io/u/mtorrisi)\ **Post date:** [March 16, 2018, 9:45am UTC](https://talk.getindico.io/t/migrate-instance/256/8 "2018-03-16T09:45:23Z")
I managed to migrate successfully the instance in the new location. Thanks a lot for the support. To get i t works, I had to drop the old indico database and recreate it, then I created the extensions again, so I was able to restore the correct DB successfully. Thanks again. ---
**Author:** ![David\_del\_Moral](https://talk.getindico.io/user_avatar/talk.getindico.io/david_del_moral/32/318_2.png) [@David\_del\_Moral](https://talk.getindico.io/u/David_del_Moral)\ **Post date:** [January 14, 2019, 9:37pm UTC](https://talk.getindico.io/t/migrate-instance/256/9 "2019-01-14T21:37:39Z")
Hi, I have also the need of coping instances between different environments (prod, qa, dev…). We cloned an instance between prod and qa using VMWare tools. Everything was fine excepting the registration forms of an event that were lost. So we have tried the steps shown above to fix the problem…after droping and restoring the database, not running the setup wizard, I’m getting the following error in the log file: ProgrammingError: (psycopg2.ProgrammingError) permission denied for schema indico [SQL: ‘SELECT indico.settings.id AS indico\_settings\_id, indico.settings.module AS indico\_settings\_module, indico.settings.name AS indico\_settings\_name, indico.settings.value AS indico\_settings\_value \nFROM indico.settings \nWHERE indic$ 2019-01-14 18:14:01,441 ERROR celery.app.trace Task event\_reminders[f628b4af-09aa-43be-b508-adeac75ae0d7] raised unexpected: ProgrammingError(’(psycopg2.ProgrammingError) permission denied for schema events\nLINE 2: FROM ev… Any clue what could be missing???. Thanks in advance for your advice. DdM ---
**Author:** ![ThiefMaster](https://talk.getindico.io/user_avatar/talk.getindico.io/thiefmaster/32/509_2.png) [@ThiefMaster](https://talk.getindico.io/u/ThiefMaster)\ **Post date:** [January 14, 2019, 9:39pm UTC](https://talk.getindico.io/t/migrate-instance/256/10 "2019-01-14T21:39:51Z")
Make sure to restore the backup as the same user indico uses to access the database (usually a user named `indico`). That way it’s guaranteed that the user will own everything in the DB. ---
**Author:** ![David\_del\_Moral](https://talk.getindico.io/user_avatar/talk.getindico.io/david_del_moral/32/318_2.png) [@David\_del\_Moral](https://talk.getindico.io/u/David_del_Moral)\ **Post date:** [January 14, 2019, 9:42pm UTC](https://talk.getindico.io/t/migrate-instance/256/11 "2019-01-14T21:42:33Z")
Thank you I’ll give a try!. Best! ---
**Author:** ![Naoya\_Ozawa](https://talk.getindico.io/user_avatar/talk.getindico.io/naoya_ozawa/32/468_2.png) [@Naoya\_Ozawa](https://talk.getindico.io/u/Naoya_Ozawa)\ **Post date:** [March 15, 2019, 9:44am UTC](https://talk.getindico.io/t/migrate-instance/256/12 "2019-03-15T09:44:50Z")
Just as a note: We have also faced the case of copying a db of one instance to another, and > [@ThiefMaster](#): > > Make sure to restore the backup as the same user indico uses to access the database (usually a user named `indico` ). That way it’s guaranteed that the user will own everything in the DB. didn’t work. When we followed this method, the `permission denied for schema` message still came up. The method we took instead was: (when moving the db from A to B) - at B: follow the [regular installation steps](https://docs.getindico.io/en/stable/installation/production/) up to Step 8 - at A: dump the DB as an `indico` user ```auto $ su - indico $ pg_dump indico -Fc -f .dump (move the dump file to B) ``` - at B: restore the DB as a `postgres` user ```auto $ su - postgres $ pg_restore -d indico -O .dump ``` At this point, the `table` and `schema` were all owned by the `postgres` user, so we changed the ownership in the following way: ```auto $ su - postgres $ psql indico $ SELECT 'ALTER TABLE ' || schemaname || '.' || tablename || ' OWNER TO indico;' FROM pg_tables WHERE tableowner ='postgres'; ``` This generated many (200 for us) lines of commands that look like ```auto ALTER TABLE categories.principals OWNER TO indico; ``` so by executing all of them, their ownerships could be changed. Note that some of the commands (55 for us) did not work due to some permission errors, but it was fine to ignore them. Then we did the same thing for another set of commands generated by ```auto $ SELECT DISTINCT 'ALTER SCHEMA ' || schemaname || ' OWNER TO indico;' FROM pg_tables WHERE tableowner ='postgres'; ``` After that the `permission denied for schema` error didn’t appear any more. The normal DB should work with just this. ---
**Author:** ![ThiefMaster](https://talk.getindico.io/user_avatar/talk.getindico.io/thiefmaster/32/509_2.png) [@ThiefMaster](https://talk.getindico.io/u/ThiefMaster)\ **Post date:** [March 15, 2019, 9:49am UTC](https://talk.getindico.io/t/migrate-instance/256/13 "2019-03-15T09:49:35Z")
`pg_restore` with the `-O` switch should be fine, we use it all the time ourselves. Getting “permission denied” for changing some ACLs or comments on plpgsql is perfectly fine in that case (there are just a few of those). The risk when restoring as superuser is that you might still end up with some things being owned by postgres instead of the Indico user. Sequences and functions for example. That might be problematic during future migrations which would then fail if the indico user cannot ALTER them. ---
**Author:** ![D\_S](https://talk.getindico.io/letter_avatar_proxy/v4/letter/d/2bfe46/32.png) [@D\_S](https://talk.getindico.io/u/D_S)\ **Post date:** [December 5, 2021, 11:04am UTC](https://talk.getindico.io/t/migrate-instance/256/14 "2021-12-05T11:04:32Z")
The amount of confusion on this topic actually demands for its own documentation page. I will try doing it on my PC. If I get it working, I’ll share the documentation. ---
**Author:** ![D\_S](https://talk.getindico.io/letter_avatar_proxy/v4/letter/d/2bfe46/32.png) [@D\_S](https://talk.getindico.io/u/D_S)\ **Post date:** [February 17, 2022, 12:10pm UTC](https://talk.getindico.io/t/migrate-instance/256/15 "2022-02-17T12:10:32Z")
I get the following error upon typing ```auto pg_restore -d indico -O indico17022022.dump ``` **Error** ```auto pg_restore: while PROCESSING TOC: pg_restore: from TOC entry 5868; 0 0 COMMENT EXTENSION pg_trgm pg_restore: error: could not execute query: ERROR: must be owner of extension pg_trgm Command was: COMMENT ON EXTENSION pg_trgm IS 'text similarity measurement and index searching based on trigrams'; pg_restore: from TOC entry 5869; 0 0 COMMENT EXTENSION unaccent pg_restore: error: could not execute query: ERROR: must be owner of extension unaccent Command was: COMMENT ON EXTENSION unaccent IS 'text search dictionary that removes accents'; pg_restore: warning: errors ignored on restore: 2 ``` Should I consider this as normal? ---
**Author:** ![ThiefMaster](https://talk.getindico.io/user_avatar/talk.getindico.io/thiefmaster/32/509_2.png) [@ThiefMaster](https://talk.getindico.io/u/ThiefMaster)\ **Post date:** [February 17, 2022, 12:12pm UTC](https://talk.getindico.io/t/migrate-instance/256/16 "2022-02-17T12:12:20Z")
Yes, you can and should ignore that error. It’s completely normal because only a superuser would be able to set these comments (which are completely irrelevant anyway).