iptables -I OUTPUT -o
service iptables save
Normally, when you want to create a MySQL backup, you either have to stop MySQL or issue a read lock on your MySQL tables in order to get a correct backup; if you don't do it this way, you can end up with an inconsistent backup. To get consistent backups without interrupting MySQL, I use a little trick: I replicate my MySQL database to a second MySQL server, and on the second MySQL server I use a cron job that creates regular backups of the replicated database.
Preliminary Note
To follow this tutorial, you need a second MySQL server (the slave), and you have to set up MySQL replication from your first MySQL server (the system from where you want to take backups, the master) to the slave, e.g. as described in this tutorial: http://www.howtoforge.com/mysql_database_replication. Setting up MySQL replication is beyond the scope of this document.
The whole setup that I describe here has to be done on the slave MySQL server!
I have tested this on a Debian system; this should work on other distributions as well, but it's possible that some paths differ (in the script /usr/local/sbin/mysqlbackup.sh).
Doing Automated Backups Of The Replicated Databases On The Slave
After you have set up a working MySQL replication from the master to the slave, I assume that you want to do automatic backups of the slave database to the directory /home/sqlbackup. First, we must create that directory:
mkdir /home/sqlbackup
Next we create the shell script /usr/local/sbin/mysqlbackup.sh that stops the slave, makes an SQL dump of the whole MySQL database in /home/sqlbackup (the file name of the SQL dump will look like this: backup-20070423-18.sql; this is a dump taken on April 23, 2007, at 18.00h), restarts the slave afterwards (the slave will then catch up on everything that has happened on the master in the meantime so that no data is lost), and deletes all SQL dumps in /home/sqlbackup that are older than two days:
vi /usr/local/sbin/mysqlbackup.sh
#!/bin/sh
datum=`/bin/date +%Y%m%d-%H`
/usr/bin/mysqladmin --user=root --password=yourrootsqlpassword stop-slave
/usr/bin/mysqldump --user=root --password=yourrootsqlpassword --lock-all-tables \
--all-databases > /home/sqlbackup/backup-${datum}.sql
/usr/bin/mysqladmin --user=root --password=yourrootsqlpassword start-slave
for file in "$( /usr/bin/find /home/sqlbackup -type f -mtime +2 )"
do
/bin/rm -f $file
done
exit 0
(Please make sure that you replace yourrootsqlpassword with the password of the root MySQL user on the slave!)
Now we must make the script executable:
chmod 755 /usr/local/sbin/mysqlbackup.sh
Of course, we don't want to run the /usr/local/sbin/mysqlbackup.sh manually; instead, we create a cron job that runs the script automatically every three hours:
crontab -e
0 */3 * * * /usr/local/sbin/mysqlbackup.sh &> /dev/null
Of course, you are free to modify the cron job to run as often as you need it.
That's it, using this method you can now back up your MySQL database without interrupting the MySQL service on the master server.
By now, many of you may be wondering why Dell is passing up such a great niche market by not offering Linux as an alternative OS option to Windows. We have talked about how this would only prove to benefit a company like Dell, but we have also acknowledged the fact that it will likely never happen.
Then I came across this piece from ArsTechnica. They rightfully point out that Dell is not equipped to handle Linux support for the desktop. And they continue their proper understanding in stating that Dell can barely handle supporting Windows issues. Then it occurred to me: why must Dell "support" Linux at all? Check this out...
This Excuse Smells of Swiss Cheese. The belief that Dell can't sell Linux based on support concerns is absurd. It’s not because problems won’t arise, but they could easily outsource this kind support to...Linux vendors themselves.
Obviously, the simple answer is to offer known-to-work hardware in Dell Linux boxes, but make it clear that on the support front, the users are on their own. Instead, Dell appears afraid of this. Why? Because they might be giving their customers over to someone competent that can actually answer the questions being asked without being put on hold 15 times? Come on, give me a break. Let's make this as easy as pie for Dell, shall we?
The "You are on Your Own" Disclaimer. Dell could force buyers, who are interested in buying the Linux alternative, to digitally sign an agreement stating that they understand that the hardware is known to work and that a list of Linux support agencies will be provided with the order. Boom, Dell just conquered the support issue.
So enough of the hot air. The reason why we will not see Dell selling desktop Linux boxes is simple - Microsoft's OEM department would come unhinged. Why? Because HP would soon follow suit. And if HP and Dell are both selling desktop Linux boxes as an alternative to Vista, the market would shift a great deal. Curiosity would prevail.
Like Linux, Vista presents a set of challenges to the PC user. And unless they dump the PC completely and just go with a Mac, most users are no worse off with Linux than with Vista. Outside of power users who need specialty apps, most people would honestly not care, so long as everything works out of the box.
The Time is Now, But Will it Even Matter? My reason to see Dell become more open to offering Linux is rather simple. If they offer it, HP will follow them, and before long, new PC buyers will be exposed to Linux offerings.
Linux is most certainly not for everyone. I get this. However, if Dell is willing to take a slight risk to look at the fact that Vista is not ready yet, they might then realize that Linux offers a viable alternative to banging-your-head-against-the-wall with Vista compatibility.
Understand this, though. Once Vista gets its issues worked out, this small window of opportunity with Dell and HP will indeed close. The time is now, so hopefully we will see enough profit margins hurting to where Dell is really ready to take a chance in offering yet, another OS option to provide along side Vista. Only time will tell, I suppose.