2017-11-26 16:44:32 -05:00
---
date: "2017-01-01T16:00:00+02:00"
2023-04-06 05:06:32 -04:00
title: "Backup and Restore"
2017-11-26 16:44:32 -05:00
slug: "backup-and-restore"
2023-07-26 00:53:13 -04:00
sidebar_position: 11
2020-12-09 01:47:06 -05:00
toc: false
2017-11-26 16:44:32 -05:00
draft: false
Refactor docs (#23752)
This was intended to be a small followup for
https://github.com/go-gitea/gitea/pull/23712, but...here we are.
1. Our docs currently use `slug` as the entire URL, which makes
refactoring tricky (see https://github.com/go-gitea/gitea/pull/23712).
Instead, this PR attempts to make future refactoring easier by using
slugs as an extension of the section. (Hugo terminology)
- What the above boils down to is this PR attempts to use directory
organization as URL management. e.g. `usage/comparison.en-us.md` ->
`en-us/usage/comparison/`, `usage/packages/overview.en-us.md` ->
`en-us/usage/packages/overview/`
- Technically we could even remove `slug`, as Hugo defaults to using
filename, however at least with this PR it means `slug` only needs to be
the name for the **current file** rather than an entire URL
2. This PR adds appropriate aliases (redirects) for pages, so anything
on the internet that links to our docs should hopefully not break.
3. A minor nit I've had for a while, renaming `seek-help` to `support`.
It's a minor thing, but `seek-help` has a strange connotation to it.
4. The commits are split such that you can review the first which is the
"actual" change, and the second is added redirects so that the first
doesn't break links elsewhere.
---------
Signed-off-by: jolheiser <john.olheiser@gmail.com>
2023-04-27 23:33:41 -04:00
aliases:
- /en-us/backup-and-restore
2017-11-26 16:44:32 -05:00
menu:
sidebar:
2023-03-23 11:18:24 -04:00
parent: "administration"
2017-11-26 16:44:32 -05:00
name: "Backup and Restore"
2023-07-26 00:53:13 -04:00
sidebar_position: 11
2017-11-26 16:44:32 -05:00
identifier: "backup-and-restore"
---
# Backup and Restore
2021-12-23 22:56:57 -05:00
Gitea currently has a `dump` command that will save the installation to a ZIP file. This
2018-01-08 17:48:42 -05:00
file can be unpacked and used to restore an instance.
2017-11-26 16:44:32 -05:00
2022-05-31 14:42:32 -04:00
## Backup Consistency
To ensure the consistency of the Gitea instance, it must be shutdown during backup.
Gitea consists of a database, files and git repositories, all of which change when it is used. For instance, when a migration is in progress, a transaction is created in the database while the git repository is being copied over. If the backup happens in the middle of the migration, the git repository may be incomplete although the database claims otherwise because it was dumped afterwards. The only way to avoid such race conditions is by stopping the Gitea instance during the backups.
2017-11-26 16:44:32 -05:00
## Backup Command (`dump`)
2019-04-10 09:34:44 -04:00
Switch to the user running Gitea: `su git` . Run `./gitea dump -c /path/to/app.ini` in the Gitea installation
2018-01-08 17:48:42 -05:00
directory. There should be some output similar to the following:
2017-11-26 16:44:32 -05:00
2019-04-10 09:34:44 -04:00
```none
2017-11-26 16:44:32 -05:00
2016/12/27 22:32:09 Creating tmp work dir: /tmp/gitea-dump-417443001
2016/12/27 22:32:09 Dumping local repositories.../home/git/gitea-repositories
2016/12/27 22:32:22 Dumping database...
2016/12/27 22:32:22 Packing dump files...
2016/12/27 22:32:34 Removing tmp work dir: /tmp/gitea-dump-417443001
2016/12/27 22:32:34 Finish dumping in file gitea-dump-1482906742.zip
```
2018-01-08 17:48:42 -05:00
Inside the `gitea-dump-1482906742.zip` file, will be the following:
2017-11-26 16:44:32 -05:00
2023-07-19 05:22:57 -04:00
- `app.ini` - Optional copy of configuration file if originally stored outside the default `custom/` directory
2023-09-04 21:26:12 -04:00
- `custom/` - All config or customization files in `custom/` .
- `data/` - Data directory (APP_DATA_PATH), except sessions if you are using file session. This directory includes `attachments` , `avatars` , `lfs` , `indexers` , SQLite file if you are using SQLite.
- `repos/` - Complete copy of the repository directory.
2020-12-09 01:47:06 -05:00
- `gitea-db.sql` - SQL dump of database
- `log/` - Various logs. They are not needed for a recovery or migration.
2017-11-26 16:44:32 -05:00
2018-01-08 17:48:42 -05:00
Intermediate backup files are created in a temporary directory specified either with the
`--tempdir` command-line parameter or the `TMPDIR` environment variable.
2017-11-26 16:44:32 -05:00
2022-05-31 14:42:32 -04:00
## Backup the database
The SQL dump created by `gitea dump` uses XORM and Gitea admins may prefer to use the native the MySQL and PostgreSQL dump tools instead. There are still open issues when using XORM for dumping the database that may cause problems when attempting to restore it.
```sh
# mysql
mysqldump -u$USER -p$PASS --database $DATABASE > gitea-db.sql
# postgres
2022-08-22 14:39:59 -04:00
pg_dump -U $USER $DATABASE > gitea-db.sql
2022-05-31 14:42:32 -04:00
```
2019-04-08 08:45:29 -04:00
### Using Docker (`dump`)
2019-04-10 09:34:44 -04:00
2019-04-08 08:45:29 -04:00
There are a few caveats for using the `dump` command with Docker.
The command has to be executed with the `RUN_USER = <OS_USERNAME>` specified in `gitea/conf/app.ini` ; and, for the zipping of the backup folder to occur without permission error the command `docker exec` must be executed inside of the `--tempdir` .
Example:
2019-04-10 09:34:44 -04:00
```none
2022-08-01 01:16:38 -04:00
docker exec -u < OS_USERNAME > -it -w < --tempdir > $(docker ps -qf 'name=^< NAME_OF_DOCKER_CONTAINER > $') bash -c '/usr/local/bin/gitea dump -c < /path/to/app.ini>'
2019-04-10 09:34:44 -04:00
```
2019-04-08 08:45:29 -04:00
2020-12-09 01:47:06 -05:00
\*Note: `--tempdir` refers to the temporary directory of the docker environment used by Gitea; if you have not specified a custom `--tempdir` , then Gitea uses `/tmp` or the `TMPDIR` environment variable of the docker container. For `--tempdir` adjust your `docker exec` command options accordingly.
2019-04-08 08:45:29 -04:00
The result should be a file, stored in the `--tempdir` specified, along the lines of: `gitea-dump-1482906742.zip`
2017-11-26 16:44:32 -05:00
## Restore Command (`restore`)
2018-01-08 17:48:42 -05:00
There is currently no support for a recovery command. It is a manual process that mostly
involves moving files to their correct locations and restoring a database dump.
Example:
2019-04-10 09:34:44 -04:00
2020-12-09 01:47:06 -05:00
```sh
2021-01-18 21:05:11 -05:00
unzip gitea-dump-1610949662.zip
cd gitea-dump-1610949662
2023-09-04 21:26:12 -04:00
mv app.ini /etc/gitea/conf/app.ini
2021-01-18 21:05:11 -05:00
mv data/* /var/lib/gitea/data/
mv log/* /var/lib/gitea/log/
2024-02-25 18:35:52 -05:00
mv repos/* /var/lib/gitea/data/gitea-repositories/
2021-01-18 21:05:11 -05:00
chown -R gitea:gitea /etc/gitea/conf/app.ini /var/lib/gitea
# mysql
2020-04-13 22:55:20 -04:00
mysql --default-character-set=utf8mb4 -u$USER -p$PASS $DATABASE < gitea-db.sql
2021-01-18 21:05:11 -05:00
# sqlite3
sqlite3 $DATABASE_PATH < gitea-db.sql
# postgres
psql -U $USER -d $DATABASE < gitea-db.sql
2018-01-08 17:48:42 -05:00
service gitea restart
```
2019-09-14 22:37:09 -04:00
2021-12-23 22:56:57 -05:00
Repository Git Hooks should be regenerated if installation method is changed (eg. binary -> Docker), or if Gitea is installed to a different directory than the previous installation.
2019-09-14 22:37:09 -04:00
With Gitea running, and from the directory Gitea's binary is located, execute: `./gitea admin regenerate hooks`
2021-12-23 22:56:57 -05:00
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.
2022-03-02 11:20:00 -05:00
2024-02-25 18:35:52 -05:00
If you still have issues, consider running `./gitea doctor check` to inspect possible errors (or run with `--fix` ).
2022-03-02 11:20:00 -05:00
### 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.
Example:
```sh
# open bash session in container
docker exec --user git -it 2a83b293548e bash
# unzip your backup file within the container
unzip gitea-dump-1610949662.zip
cd gitea-dump-1610949662
# restore the gitea data
mv data/* /data/gitea
# restore the repositories itself
2023-09-04 21:26:12 -04:00
mv repos/* /data/git/gitea-repositories/
2022-03-02 11:20:00 -05:00
# adjust file permissions
chown -R git:git /data
# Regenerate Git Hooks
/usr/local/bin/gitea -c '/data/gitea/conf/app.ini' admin regenerate hooks
```
The default user in the gitea container is `git` (1000:1000). Please replace `2a83b293548e` with your gitea container id or name.
### Using Docker-rootless (`restore`)
The restore workflow in Docker-rootless containers differs only in the directories to be used:
```sh
# open bash session in container
docker exec --user git -it 2a83b293548e bash
# unzip your backup file within the container
unzip gitea-dump-1610949662.zip
cd gitea-dump-1610949662
# restore the app.ini
mv data/conf/app.ini /etc/gitea/app.ini
# restore the gitea data
mv data/* /var/lib/gitea
# restore the repositories itself
2023-09-04 21:26:12 -04:00
mv repos/* /var/lib/gitea/git/gitea-repositories
2022-03-02 11:20:00 -05:00
# adjust file permissions
chown -R git:git /etc/gitea/app.ini /var/lib/gitea
# Regenerate Git Hooks
/usr/local/bin/gitea -c '/etc/gitea/app.ini' admin regenerate hooks
```