The Problem
How much does it take you to write a blog post? What about 100 posts? What about writing the blog engine itself?
What if you suddenly loose everything? What if it was not your fault and your hosting provider does not backup your data? This is an extreme (but not unlikely) case.
What if you suddenly loose everything? What if it was not your fault and your hosting provider does not backup your data? This is an extreme (but not unlikely) case.
Yesterday, I was greeted by an error page from all of my websites.
The problem was due to MySQL related issues. Fortunately, Webfaction is run by clever developers who solved the issue in a matter of minutes. They backup data, as well. However, hosting providers are not required to do backups of your data on a hourly basis, not even on a daily basis.
This made me think. Since the infamous black day where I (stupidly) lost 6 years of data, I occasionally do a manual backup of my web applications and store them on my computer and external storage. What about a shell script that automatically backups all of our web application’s files and databases, and optionally uploads everything to DropBox?
The Solution
Here is my solution:
Download
You can download the script here.
Configuration
The script assumes that all the websites and web applications live under the same directory, e.g., /home/dgraziotin/webapps.
It also assumes that each web application can have up to one MySQL (or PostgreSQL) database and a database user with full access on it. On Webfaction, each new database is accompanied by the creation of a user with the same name of the database. Only this user can access to the database. This is an elegant (and secure) solution, which should be employed on any other hosting platform and server.
We store all the information in the file /home/yourusername/.backup_passwd.
Below is an example of the password file:
It also assumes that each web application can have up to one MySQL (or PostgreSQL) database and a database user with full access on it. On Webfaction, each new database is accompanied by the creation of a user with the same name of the database. Only this user can access to the database. This is an elegant (and secure) solution, which should be employed on any other hosting platform and server.
We store all the information in the file /home/yourusername/.backup_passwd.
Below is an example of the password file:
The provided password file contains three entries.
The first one refers to the website myblog, using a MySQL database calleddgraziotin_myblog. The user dgraziotin_myblog accesses it with the passwordsaD23fWffFEfwg.
The second entry refers to a website called landing_page, not using any database at all.
The third entry is for a website called myecommercesite. It uses a PostgreSQL databas,dgraziotin_esite. The user dgraziotin_esite owns it with the password DFWkf3kf24KGKf.
The first one refers to the website myblog, using a MySQL database calleddgraziotin_myblog. The user dgraziotin_myblog accesses it with the passwordsaD23fWffFEfwg.
The second entry refers to a website called landing_page, not using any database at all.
The third entry is for a website called myecommercesite. It uses a PostgreSQL databas,dgraziotin_esite. The user dgraziotin_esite owns it with the password DFWkf3kf24KGKf.
Regarding Dropbox integration, install first Dropbox-Uploader and uncomment the last four lines of the script. Adjust the path of dropbox_uploader.sh to where you put the script.
How does it work?
The script exploits the Internal Field Separator of GNU/Linux to define the separator to identify patterns of text.
At line 36, we set the IPS to \n, or newline. Because of this, the for loop at line 38 will iterate every line of the password file.
Within the for loop, we set IPS to " ", or space character.
Each line is split up to three times, according to the number of space character encountered. These three substrings are stored in the variables APP_NAME, DB_NAME, andDB_USER.
These values are used in lines 49-51 to create a bzipped archive of the website (or the web application).
In lines 53-63 we create a bzipped archive of the database (MySQL or PostgreSQL), if the database has been defined in the password file.
Within the for loop, we set IPS to " ", or space character.
Each line is split up to three times, according to the number of space character encountered. These three substrings are stored in the variables APP_NAME, DB_NAME, andDB_USER.
These values are used in lines 49-51 to create a bzipped archive of the website (or the web application).
In lines 53-63 we create a bzipped archive of the database (MySQL or PostgreSQL), if the database has been defined in the password file.
I am using it through a cronjob to backup all of my websites. I hope that someone else finds it useful, too. Feel free to comment on this post to report possible bugs.
No comments:
Post a Comment