Best Practices for Writing Safe Shell Scripts for MySQL Backup

Introduction Operations engineers should write civilized scripts; this guide shows how to avoid "rogue" behavior by adding proper logging, usage help, locking, and documentation.

Example Scenario We illustrate the concepts using a MySQL database backup shell script.

Logging Function A dedicated shell_log function records start, success, and other events, making it easy to trace when the backup runs.

[root@linux-node2 shell]# catshell_template.sh.log 2016-08-27 06-01-19 : shell_template.sh :shell beginning ,write log test 2016-08-27 06-01-19 : shell_template.sh :shell success ,write log test

Usage Help A shell_usage function prints usage information (e.g., Usage: ./shell_template.sh {backup} ) so users know how to invoke the script safely.

[root@linux-node2 shell]# ./shell_template.sh Usage: ./shell_template.sh {backup}

File Locking To prevent concurrent executions, shell_lock and shell_unlock create and remove a lock file. If the lock exists, the script exits, avoiding overlapping runs that could corrupt data.

Test the lock by opening another terminal or checking /tmp for the lock file; remember to clean up the lock file on abnormal exits.

Documentation and Attribution Add clear comments describing the script’s purpose and author information so future maintainers know who wrote it.

For those interested, the full script template is available for download at the following link:

https://www.unixhot.com/article/60