audrey/mysql-backup-agent
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update readme.md
All checks were successful
Build Container Image & push to Packages / Build package (push) Successful in 43s
Details

Browse Source 
add restore instructions
This commit is contained in:
audrey 2025-04-07 20:08:30 +00:00
parent 6994c3373a
commit a32151f89f
1 changed files with 29 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
readme.md
View File

@ -7,7 +7,7 @@ Every night at 23:50, internal cron runs `mysqldump` to dump all databases on th
By default, the job is confirued to run at 23:50 every night.
> [!IMPORTANT]
> The crontab file (mysqlCron) must always contain an empty line at the end of the file.
```
``` sh
50 23 * * * backup.sh >> /var/log/cron.log 2>&1
- - - - -
| | | | |
@ -25,7 +25,7 @@ The service needs to have network access to the target server on a network that
It's recommended to set up this container by adding it to the target service's docker compose.
### Examples
#### Simple Setup
```
``` yaml
version: "3"
services:
db:
@ -62,7 +62,7 @@ For increased data security, it's recommended to store database backups on the N
The below example is identical to the one above, except `APPEND_DATE` has been set to `false` & the volume definition for `backup` has been modified.
> [!IMPORTANT]
> If you intend to keep regular snapshots of this backup on the file server, you should set APPEND_DATE to false
```
``` yaml
version: "3"
services:
db:
@ -112,3 +112,29 @@ Some basic config options are available through environment variables.
| :--- | :--- | :---|
|APPEND_DATE|`Default: false` If set, appends the yyyy-mm-dd of the backup to the end of the file name. Leaving this unset will cause existing backups to be overwritten.| `APPEND_DATE=true`|
|BACKUP_NAME|`Default: Value of MYSQL_HOST`If set, the name of the file will be set to this value. Example: setting this to 'epicdb' will cause files to save as 'epicdb.sql'|`BACKUP_NAME='pubweb-backup'`|
## Recovery
Recovering from a MySQL dump is a very manual process. There's no one method to do it. Generally, all you need to do is download the latest dump from the NAS/backup target & import it into the MySQL database.
For simple services, it may be sufficient to delete the faulty MySQL data & rebuild it from the dump. To do so, delete the existing volume for MySQL then simply bind the directory containing the backed-up SQL dump file to the MySQL container's entrypoint dir. Review the below Compose.yaml for an example:
``` yaml
version: "3"
services:
db:
image: mysql:latest
container_name: pubwebdb
restart: always
volumes:
- "db:/var/lib/mysql"
- "backup:/docker-entrypoint-initdb.d:r"
volumes:
db:
driver: local
backup:
driver: local
driver_opts: #config to connect to an NFS share is defined using these options
type: nfs
o: addr=172.16.1.2,rw #If a direct link is available, use that
device: :/mnt/tank/Docker/Volumes/Pubweb #this will usually be the path to the folder shared by NFS, relative to the file server.
```
When MySQL starts, it should detect an empty database (if this doesn't happen, make sure you deleted the persistent volume that was mapped to /var/lib/mysql.) This will trigger it to check /docker-entrypoint-initdb.d for any .sql files it can execute to populate itself. Once the prepopulation has been completed, you can comment out the volume binding.
If `APPEND_DATE` is set to true, you'll need to make sure this directory contains only the SQL dump you want to restore. Move all others somewhere safe.