Restoring a site from a copy during installation

You are moving to another host or rebuilding a site after a failure, and you have a database copy made by this engine. The installer can restore the site from it instead of creating an empty one.

What you need

• the engine unpacked on the new host and an empty database (or another table prefix);
• the copy file: .sql, .sql.gz or an encrypted .sql.gz.enc made in “Database copies” or with the db:backup command;
• for an encrypted copy, the recovery key that was shown when encrypted copies were turned on;
• the install code: the file storage/install-code.txt. Without it the installer lets nobody in.

Step by step

• On the installer’s first screen click “I already have a Nex1on site — restore it from a copy”.
• Language, server check and database are the same steps as for a new site. The table prefix must match the one in the copy: if it does not, the installer tells you which to enter.
• Put the copy file into the folder storage/import over FTP and click “Refresh the list”. A file cannot be uploaded from the browser: hosts cut the upload size.
• Pick the file (for an encrypted copy enter the recovery key) and click “Check the copy”. The check only reads: it writes nothing to the database and shows the number of tables and recorded updates.
• “Restore the site”. It takes from seconds to a few minutes; keep the window open. If it stops halfway, check the copy again and repeat: only the tables of that attempt are removed.
• “Whose site is this?”: choose your account among the owners and either prove it with the old password or set a new one. Until you do, nobody can sign in with an administrator account.

What comes back

Users, entries, pages, comments, orders and site settings — as in the copy.

What is deliberately not carried over

• sessions, “remember me”, password-reset and invitation links, social sign-in links;
• API keys and app sign-ins, notification subscriptions, preview links, webhook history;
• queues: emails waiting to be sent and mailings in progress (mailings come back as drafts);
• the update source and licence check, trusted proxies and access limits, off-site copies, AI and social keys — return to defaults; webhooks are off;
• mail is switched to “to a file” until you set it up again;
• two-step sign-in is turned off for everyone: its secret cannot be read on the new site;
• administrators and moderators stay locked until the owner confirms themselves; open the ones you need in “Users”;
• uploaded files (the uploads folder) are not part of a database copy: copy them over FTP.

What to do afterwards

• set up mail again (“Settings” → “Mail”) and send a test email;
• enter the licence key again (“System” → “Updates”) and the keys and passwords that were encrypted on the old site: off-site copies, captcha, social sign-in, AI;
• turn two-step sign-in back on where it was used;
• open the administrators and moderators you need in “Users”;
• check the site address in settings and, if the domain is new, the redirect from the old one.

Safety

The file is checked before anything is written: only the engine’s ordinary copy statements are accepted (creating its own tables and inserting rows). Any other statement in the file means a refusal, “The file does not look like a safe copy”, and nothing is written. The copy file holds password hashes and email addresses: when the restore is done, remove it from the server with “Delete the copy file”.