backing of linux server
 

Hi all,

we have a web application runs in our server through tomcat with database mysql server.

I have a backup script that runs once in day.But the clients who are accessing our applications use to upload some documents in server.

So is there any way to back up the server and also the mysql database when any new information is being uploaded.

So that we can restore with full data in case of any crashes.

Your suggestions please.

Thanks in advance,
Dinesh.

dependant on the nature of the backup
 

What is the nature of the backup? Is it a completely replica? Archive? ... etc.


You could write a script using something like tree() or: find . -depth; or: ls -aR; on both directories and check for whether there is a difference and if you find one then return the backup command...
Or You could write a script using diff() andor cmp().
Or you could use dircmp(), but not all distros ship with it. My Slack box ships without cmpdir(), and I'm pretty sure your CentOS ships without as well.
Or you could use a view only command on the backup archive, such as: tar -tf; and compare it to your current directory listings...

Check the man pages for further customising of the functions above

Hi cin,

Thanks for your reply, will try that, is there a way to back up mysql database automatically when a new entry is added to it.

nature of changes
 

From a cursory glance at...
... it seems to lack automatic backing, but you should check out what other options there are, perhaps one will do what you need...
Look into http://dev.mysql.com/doc/refman/5.0/en/binary-log.html
It seems one way MySQL can log changes. Perhaps you could use the log in conjunction with a script you write to run the backup in case of change and have the script patrol your log from cron...?

Or there could be an easier way...
How are you making the changes?
What changes are you making? To the database schema? Or files within?

I use RAID1 and AoE (ATA over Ethernet).

Here is how it works:
1) use AoE to "export" the block device of another box to your server.
2) make a RAID1 using the local drive and the "remote" drive

example:
3) from now on, whatever is written on the local drive is replicated on the remote drive, so if disaster strikes you have a backup (which is physically outside your server). No need for complex scripts that replicate info every X seconds.

Note: you can use RAID5 or RAID6 if you want.

MySQL certainly does have the capability of logging changes. See http://dev.mysql.com/doc/refman/5.1/...p-methods.html for a variety of options for backup. In particular, if you enable binary logging, you will be able to recover to any point in time.

You could also implement Zmanda Recovery Manager (ZRM) for MySQL -- http://www.zmanda.com/backup-mysql.html. It uses the native tools of MySQL and integrates them into a managed backup system for your database. You can use that to pull backups to another server on a regular schedule if you wish.

You should have a look at LVM snapshots. Using LVM snapshots you a guaranteed file system consistency. Haven't used it myself yet, but from what I know it may suit your needs.

- kenneho

Hi all,

Thank you very much for your replies.

I have one doubt, is copying /var/lib/mysql is a good alterntive to mysqldump?.

Because i use rsync to copy /var/lib/mysql for back up without dumping the database. I use rsync to do differential backup up so that it copies /var/lib/mysql to /var/tmp every one minute.

Does this idea worths or will it create any other problems.

Your suggestions please.

Thanks&regards,
Dinesh.

Thanks..

An LVM snapshot does not guarantee file system consistency. It reduces your exposure to change and the risk of inconsistencies.

If you have things running on your system that keep data and write it to disk, and you do a backup, then things can change on the disk while you are doing the backup. If you take a snapshot, and then backup the snapshot, then you don't have the ongoing exposure to change while the backup is being done. However, there could still be inconsistencies at the point in time when the snapshot was taken, because you have live applications running. This would be especially true of databases.

In order to be sure you have no inconsistencies, your system must be quiescent. That is, applications that might have data in memory, or things partially written out to different locations on disk, must be stopped, flushed, locked, whatever terminology and methods are appropriate for the application. Then you take the snapshot, start them up again, and proceed to backup the snapshot.

Going back to http://dev.mysql.com/doc/refman/5.1/...p-methods.html (referenced in my first post), the description of the use of snapshots for MySQL backup is at the end of that page. It's one way of doing it, but it isn't a complete solution. You need the binary logging to get incremental backups recoverable to any point in time. So, read the whole page and choose the method(s) most appropriate for your needs.

See my previous post and the link. Copying /var/lib/mysql risks inconsistencies when you recover, unless you go through the steps of flushing and locking tables and logs in MySQL. Then, to reduce the amount of time you have to leave tables locked, you can use some kind of file system snapshot. Following the recommendations from the MySQL site could avoid later problems when you need to recover.

Generally speaking, you may get away on backing up your databases by copying /var/lib/mysql instead of using mysqldump. All of this depending on your environment.

However like choogendyk mentioned, you may look into database inconsistencies when it comes time to recover a database or a table.

One IMPORTANT thing to note is that recovering from /var/lib/mysql backups will only work if your database tables are not using the InnoDB storage engine. (Default starting MySQL 5.5)
By default MySQL keeps all the data of all InnoDB tables on two single data files. This means if your server has multiple databases that have InnoDB tables in them, recovering from the data file will certainly will affect ALL tables with that storage engine.

Ideally I would stick with mysqldump, disk storage is really cheap now days.