You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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 nodata/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:
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:
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
The text was updated successfully, but these errors were encountered: