Solution#174
Conversation
mateacademy-ai-mentor
left a comment
There was a problem hiding this comment.
Review Summary
Your solution is approved because it meets all the core functional requirements: you back up ShopDB with mysqldump, restore it into ShopDBReserve, and create a data-only backup that is restored into ShopDBDevelopment, all while reading credentials from DB_USER and DB_PASSWORD and requiring no script arguments. The ShopDBReserve database receives a full schema + data copy, ensuring the Products table exists with the same row count, and the development database only receives data (using --no-create-info), which respects the requirement not to copy schema from production.
The main concerns with your script are robustness issues, not functional blockers: you don’t currently validate that DB_USER/DB_PASSWORD are set before running mysqldump/mysql, and you rely on relative paths (backup.sql, backupdev.sql), which can be brittle when running under cron from an unexpected working directory. These are worth improving so that failures are easier to diagnose and cron behavior is more predictable, but they don’t prevent the script from satisfying the stated task requirements. As a next step, consider adding a small guard like : "${DB_USER:?DB_USER not set}" and either using absolute paths or cd-ing into a known directory before creating and restoring backup files.
Overall, you’ve implemented the requested behavior correctly; tightening environment checks and path handling will make this a more reliable backup script in real-world cron usage.
✨ Please rate this review in the Platform's notification center1. I will be grateful for your feedback! ✨
Footnotes
| @@ -1 +1,7 @@ | |||
| #! /bin/bash | |||
|
|
|||
| mysqldump -u $DB_USER -p$DB_PASSWORD ShopDB --no-create-db --result-file=backup.sql | |||
There was a problem hiding this comment.
You're not checking whether DB_USER and DB_PASSWORD are set before running mysqldump; adding a simple guard with a clear error message would make failures under cron much easier to understand.
| #! /bin/bash | ||
|
|
||
| mysqldump -u $DB_USER -p$DB_PASSWORD ShopDB --no-create-db --result-file=backup.sql | ||
| mysql -u $DB_USER -p$DB_PASSWORD ShopDBReserve < backup.sql |
There was a problem hiding this comment.
Relying on backup.sql in the current directory can be brittle when this script is run via cron; consider using an absolute path or cd to a known directory before creating and restoring this file.
| mysqldump -u $DB_USER -p$DB_PASSWORD ShopDB --no-create-db --result-file=backup.sql | ||
| mysql -u $DB_USER -p$DB_PASSWORD ShopDBReserve < backup.sql | ||
|
|
||
| mysqldump -u $DB_USER -p$DB_PASSWORD ShopDB --no-create-db --no-create-info --result-file=backupdev.sql |
There was a problem hiding this comment.
Similarly to the previous backup, using a relative backupdev.sql file may fail or clash under cron; it’s safer to control the working directory or use absolute paths for backup files.
No description provided.