Download the latest version of this program using the following URLs:
Unpack the downloaded archive file in a directory accessible by your webserver (e.g "public_html/db_backup/").
# mkdir public_html/db_backup
# cd public_html/db_backup
# wget http://restkultur.ch/personal/wolf/scripts/db_backup/db_backup-latest.tar.gz
# tar -xzvf db_backup-latest.tar.gz db_backup
c:\> mkdir "C:\Program Files\Apache Group\Apache\htdocs\db_backup" c:\> cd "C:\Program Files\Apache Group\Apache\htdocs\db_backup"Download and Unzip all files from db_backup-latest.zip to your newly crated directory.
Without some customization, the script will not work. Most important are the MySQL server settings and the directory where to store the backup files. Open the file "def_config.inc.php" in your favourite text- editor (e.g. vim or notepad) and change at least the following parameters/lines:
$cfg['backup_dir'] = '/home/user/public_html/db_backup/data';
$cfg['backup_host'] = 'www.example.com';
$cfg['db'][$i]['db_name'] = 'my_db_name';
$cfg['db'][$i]['host'] = 'localhost';
$cfg['db'][$i]['user'] = 'demouser'; $cfg['db'][$i]['password'] = 'demopassword';
All other settings are not mandatory or should work on most systems without change.
The comments in the configuration file should be self-explanatory. If you have questions or suggestions, regarding the configuration, then please, don't hesitate to contact me. My aim is to keep configuration and usage of the script as easy as possible, despite the numerous options.
When finished save your file under the filename "config.inc.php".
Running the backup script for the first time.
Now we can test the our new installation for the first time. Point your browser to the url where you were installing the backup script (e.g. http://www.example.com/db_backup/db_backup.php) At first you will notice, that nothing seems to happen. Be patient. The whole backup process is logged an displayed to the user only after completion. The time needed for backup depends on the size of your database and usual factors like, cpu-speed, available memory etc. On my Windows 2000 desktop-system running on a AMD 1.2Ghz CPU with 768MB RAM it takes about two minutes for backing up a database of approx. 8MB in size. On my ISPs system running on a optimized Red-Hat Linux webserver configuration, it takes around ten seconds for the same database. Read the displayed report carefully, and check if everything works as expected. You may have to further change configuration values in the file config.inc.php and try again.
I recommend you let the script save your backup files in a directory, outside your webroot, so there is no chance, that a malicious attacker can get hold of your entire database contents. However this is only a recommendation. Some users my prefer to put them somewhere, to be downloadable from anywhere with their browser. In this case, you should at least password-protect the directory with a .htaccess file or other means of securing webpages from public access. Check your webserver documentation for more informations about securing locations of your webserver.
I also strongly recommend securing the location of the backup scripts. For two reasons: 1) The configuration file config.inc.php contains username and passoword of your MySQL server account in cleartext. 2) Website visitors may deliberately fire-up your backup scripts, thus overwrting older backup files and stressing you webserver. You should password-protect the directory with a .htaccess file or other means of securing webpages from public access. Check your webserver documentation for more informations about securing locations of your webserver.
The best use of the backup_scripts is in some sort of automated execution on a daily basis. Like this the backup-cycles defined in you configuration files for daily, weekly and monthly snapshots of your database are performed regularly, without your intervention. Following is brief guide how to run a schduled automatic daily backup on Unix and Windows systems. For the following you need some sort of shell access to your webhost-account. Far from all Webhosting providers allow this. Check with you ISP, or ask him, if he could do it for you.
Some providers also allow to execute php-scripts directly from the command-line. You can test this as follows:
# php -v
You should get an output that looks more ore less as the following:
PHP 4.3.6 (cli) (built: Apr 14 2004 17:21:48) Copyright (c) 1997-2004 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
If this works and the version number is right too, then you don't need to use wget to invoke you script by the cron daemon. Just put "php" instead of "wget ..." at the beginning of your cron command line and change the path to script to your local filesystem path. I.e. something like this.
"0 0 * * * php /home/userdir/public_html/db_backup/db_backup.php"
You can fetch webpages from a unix command-line using the "wget" program. we hereby use "wget" to invoke our script. Check your system-documentation or man page for details on using wget (e.g. # man wget) First check if the wget command produces the desired result,by invoking it directly from the command-line: The following example assumes that you have protected the script-directory with a user named "webuser" and the password "webpassword". After the execution a file called "db_backup.php.html" should be found in the directory "public_html", like this you can view it by pointing your browser to "http://www.example.com/db_backup.php.html". The "--verbose" switch is added to see any error messages from wget during this test.
# wget --verbose --http-user=webuser --http-passwd=webpassword --html-extension --directory-prefix=public_html/ http://www.example.com/db_backup/db_backup.php"
If your wget command-line looks ok, and produces the desired result, you can add it as a scheduled cron-job:
"MAILTO = webmaster@example.com"
"0 0 * * * wget --http-user=webuser --http-passwd=webpassword --html-extension --directory-prefix=public_html/admin http://www.example.com/db_backup/db_backup.php"While the "0 0 * * * " stands for midnight every day. Check the crontab and cron documentation for other possibilities in planning a cron-scheduled job. Use the same command-line as in our test earlier, just ommit the "--verbose".
# crontab cronjobsWhile cronjobs is the name of the textfile you just wrote. You can display the defined jobs using the following command to see if it is registred right:
# cronatab -l
C:\> at 0:00 /EVERY:m,t,w,th,f,s,su "c:\php\cli\php.exe C:\Program Files\Apache Group\Apache\htdocs\db_backup\db_backup.php"
C:\> at 0:00 /EVERY:m,t,w,th,f,s,su "wget --http-user=webuser --http-passwd=webpassword --html-extension --directory-prefix=public_html/admin http://www.example.com/db_backup/db_backup.php"
If none of the options described abobe works for you, you can still invoke the script on regular basis from you home-pc or office workstation by scheduling a command wich starts your default browser automatically at a given time and executes the script on your webserver.
C:\> at 0:00 /EVERY:m,t,w,th,f,s,su " http://webuser:webpassword@www.example.com/db_backup/db_backup.php"
In that case you just have to make sure, that your computer is turned on.
...
C:\> D: D:\> cd \path\to\backup\dir\days\ D:\path\to\backup\dir\days\> copy *.2004-01-19.sql db_name.2004-01-19.sql D:\path\to\backup\dir\days\> c:\mysql\bin\mysql -D db_name -u user_name -p password < db_name.2004-01-19.sql
# cd /path/to/backup_dir/days # cat *.2004-01-19.sql > db_name.2004-01-19.sql # /usr/local/mysql/bin/mysql -D db_name -u user -p pass < db_name.2004-01-19.sql
...
more to come ...