forked from gitea/gitea
1
0
Fork 0

Improve Documentation for Restoration from backup (#29321)

Comment the default path for repos and suggest using doctor for when
things are stuck
This commit is contained in:
kralo 2024-02-26 00:35:52 +01:00 committed by GitHub
parent 49e4826747
commit f13f93261e
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 3 additions and 1 deletions

View File

@ -92,7 +92,7 @@ cd gitea-dump-1610949662
mv app.ini /etc/gitea/conf/app.ini mv app.ini /etc/gitea/conf/app.ini
mv data/* /var/lib/gitea/data/ mv data/* /var/lib/gitea/data/
mv log/* /var/lib/gitea/log/ mv log/* /var/lib/gitea/log/
mv repos/* /var/lib/gitea/gitea-repositories/ mv repos/* /var/lib/gitea/data/gitea-repositories/
chown -R gitea:gitea /etc/gitea/conf/app.ini /var/lib/gitea chown -R gitea:gitea /etc/gitea/conf/app.ini /var/lib/gitea
# mysql # mysql
@ -111,6 +111,8 @@ With Gitea running, and from the directory Gitea's binary is located, execute: `
This ensures that application and configuration file paths in repository Git Hooks are consistent and applicable to the current installation. If these paths are not updated, repository `push` actions will fail. This ensures that application and configuration file paths in repository Git Hooks are consistent and applicable to the current installation. If these paths are not updated, repository `push` actions will fail.
If you still have issues, consider running `./gitea doctor check` to inspect possible errors (or run with `--fix`).
### Using Docker (`restore`) ### Using Docker (`restore`)
There is also no support for a recovery command in a Docker-based gitea instance. The restore process contains the same steps as described in the previous section but with different paths. There is also no support for a recovery command in a Docker-based gitea instance. The restore process contains the same steps as described in the previous section but with different paths.