74 lines
2.8 KiB
Markdown
74 lines
2.8 KiB
Markdown
[KUBE](../README.md) / Restore
|
|
|
|
# Restore
|
|
|
|
The restore process is divided into three stages:
|
|
1. Restoring website files from the `<domain>` directory or the `<domain>.tar.gz` archive.
|
|
2. Restoring the `<domain>.conf` file.
|
|
3. Restoring the database from the `<domain>.sql` file or the `<domain>.sql.tar.gz` archive.
|
|
|
|
> [!WARNING]
|
|
> If an error occurs at any stage, the process does not stop.
|
|
|
|
> [!WARNING]
|
|
> Files, databases, and other resources at each stage are either pre-cleaned or immediately overwritten without confirmation.
|
|
|
|
|
|
## Commands
|
|
|
|
### `-r, --restore <domain> [action]`
|
|
Restore site files and database from backup for a `domain`.
|
|
|
|
Example:
|
|
```bash
|
|
sudo kube.sh -r example.com
|
|
```
|
|
|
|
The source of resources for recovery is the directories defined in `backupPath` and `backupLongTermPath`.\
|
|
In the backup folder is searched for 3 types of resources:
|
|
- `<source path>/<date>/<marker>/<domain>` - directory with site files (`file:d`)
|
|
- `<source path>/<date>/<marker>/<domain>.tar.gz` - site file archive (`file:a`)
|
|
- `<source path>/<date>/<marker>/<domain>.sql` - site database SQL-file (`db:f`)
|
|
- `<source path>/<date>/<marker>/<domain>.sql.tar.gz` - site database archive (`db:a`)
|
|
- `<source path>/<date>/<marker>/<domain>.conf` - site database archive (`conf`)
|
|
|
|
The search results in a list of format: `<counter>: <data> <marker> [<list of resource>]`. Then you should specify the number of the selected marker for restore.
|
|
|
|
> [!NOTE]
|
|
> If one resource is selected (`file:d`/`file:a`/`db:f`/`db:a`/`conf`), only one resource will be restored. The other will remain unchanged.
|
|
|
|
> [!NOTE]
|
|
> If there's a `file:d` and a `file:a`. Priority is given to `file:d`. If there's a `db:f` and a `db:a`. Priority is given to `db:f`.
|
|
|
|
> [!NOTE]
|
|
> Once database are restored, the Redis keys for the domain are deleted.
|
|
|
|
Example:
|
|
```bash
|
|
1: 2025-04-29 14-22-22 [file:d file:a db:f conf]
|
|
2: 2025-04-29 14-20-20 [file:d db:a]
|
|
3: 2025-04-29 12-00-00 [file:a conf]
|
|
4: 2025-04-29 _first [db:a]
|
|
```
|
|
|
|
You can specify an additional parameter after the domain:
|
|
- `list` - will display a list of available markers for restore
|
|
- `last` - automatic site restore from the `last backup`
|
|
- `full` - automatic site restore from the last `FULL backup`
|
|
- `auto` - automatic site restore from the last `FULL backup` or the `last backup`
|
|
- `N` - automatic site restore from the `last backup #N` (N: 1+)
|
|
|
|
`FULL backup` is a backup that contains a copy of the site files, a copy of the database, and a copy of the .conf file\
|
|
`last backup #N` marker number (starting from 1) in the list sorted by creation time (can be seen with the list command)
|
|
|
|
Example:
|
|
```bash
|
|
sudo kube.sh -r example.com list
|
|
sudo kube.sh -r example.com last
|
|
sudo kube.sh -r example.com auto
|
|
sudo kube.sh -r example.com 3
|
|
```
|
|
|
|
> [!WARNING]
|
|
> Restoring from the last full copy will be done without question.
|