Skip to content

Gitea restore from documentation seems incomplete/outdated #25878

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
rnveach opened this issue Jul 14, 2023 · 3 comments · Fixed by #26902
Closed

Gitea restore from documentation seems incomplete/outdated #25878

rnveach opened this issue Jul 14, 2023 · 3 comments · Fixed by #26902
Labels
type/docs This PR mainly updates/creates documentation

Comments

@rnveach
Copy link

rnveach commented Jul 14, 2023

Description

Sorry that this is based on a pretty old version of gitea. I didn't think I let it get this far out of date. I apologize if most of this has changed and thats why the documentation didn't line up and the DB dumps have changed. I plan to try upgrade gitea once I am finished this.

I follow https://docs.gitea.com/administration/backup-and-restore to create my own backups incase of an issue during upgrades using sudo -u git gitea dump -c /etc/gitea/app.ini -w /var/lib/gitea.

I just recently did a re-install from a format and I had to follow the https://docs.gitea.com/administration/backup-and-restore#restore-command-restore portion of the process and ran into multiple issues and it seems like the documentation is out of date.

Unzipping the zip file doesn't create a gitea-dump-* folder. The zip contains the following items in the base folder (for me): data, repos, app.ini, gitea-db.sql . There is no data/conf/app.ini , log/* which are used in the next steps. /etc/gitea/conf/app.ini is /etc/gitea/app.ini for me. /var/lib/gitea/repositories/ is /var/lib/gitea/data/gitea-repositories. The specific locations may be installation dependent, but I figure whats contained in the backup file would be consistent.

The other thing that made think is: if I am doing a restore on an existing installation, shouldn't some of these commands include a deletion of the old directories to wipe things clean?

The database restore was the most problematic. I am using mysql 8.0.33 . Just to note, when I started the DB restore, gitea probably already did its own setup (since I had to reboot multiple times), so maybe some of this was so problematic since it was like I had an existing installation.

When I ran the command the first time, it errored out on duplicate indexes:

# mysql --default-character-set=utf8mb4 gitea <gitea-db.sql
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1061 (42000) at line 5: Duplicate key name 'UQE_email_hash_email'

This line was CREATE UNIQUE INDEX UQE_email_hash_email ON email_hash (email);.

The next thing I tried was to manually remove all the indexes from the table, as I figured the restore would restore them since it had them and that was what it was failing on. The next time I ran the command, I got this:

# mysql --default-character-set=utf8mb4 gitea <gitea-db.sql
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1062 (23000) at line 7542: Duplicate entry 'runtime-state' for key 'app_state.PRIMARY'

This line was INSERT INTO app_state (id, revision, content) VALUES ('runtime-state',0,'{"last_app_path":"/usr/local/bin/gitea"}');.

When I got here, I was worried that this was duplicating rows in the DB as there does not appear to be any deletes for an existing installation (this is where my other thought came from).

It was at this point that I decided to abandon restoring the DB from this file, and restored from a direct mysqldump I made before formatting. I used this and my restoration was complete and I appear to be up and running again (but I am sure I need to test things more).

One thing from this process I think should be added is that I didn't see an easy place to determine which version of gitea created the dump. Even if its just for display and not used at all, it might be beneficial for this to be put somewhere in the dump. Maybe this could be added to app.ini. I forgot to write down what version I had installed prior.

Gitea Version

1.17.3

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

N/A

Screenshots

N/A

Git Version

2.34.1

Operating System

LUbuntu 22.04.2

How are you running Gitea?

Followed https://docs.gitea.io/en-us/install-from-binary/ and used https://docs.gitea.io/en-us/linux-service/ to start it as a service.

Database

MySQL

@rnveach
Copy link
Author

rnveach commented Jul 15, 2023

I upgraded to 1.19.4, started, left it running for a bit, then stopped and created a new back and confirmed nothing has changed from my comments from above on the backup.

@puni9869
Copy link
Member

Just want to re-confirm, the problem is still exist or not after upgrade.

@rnveach
Copy link
Author

rnveach commented Jul 21, 2023

The problems I mentioned in my first post are still valid after the upgrade to the latest version.

@lunny lunny added type/docs This PR mainly updates/creates documentation and removed type/bug labels Jul 27, 2023
lunny pushed a commit that referenced this issue Sep 5, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type/docs This PR mainly updates/creates documentation
Projects
None yet
3 participants