Backing system up using dump

X

xy16644

I am still really new to using the dump utility. Currently I have a mirrored drive configuration in my FreeBSD server and I use the following command to back it up:
Code: 
dump -0af machinename-date.tar /dev/mirror/RootMirror4s1a

This creates a tar file of about 2GB for a system that uses 7.5GB of disk space. I do use MySQL so I was wondering, do my databases get backed up using the command above? Does everything else get backed up to that tar file?

When I look at the options for dump I noticed there is a -L option for a "live system". I have tried the following unsuccessfully:
Code: 
dump -0afL /dev/mirror/RootMirror4s1a

Whats the correct way of using dump with the -L option? When does one use the -L option?

What I am looking for it a way to COMPLETELY backup my system. Am I asking too much from the dump command? Is there a better way to approach backing up my entire system?

Many thanks. :e
 
Dump dumps a complete filesystem. The commands you used only dumps the RootMirror4s1a filesystem. Depending on where you stored your mysql databases this may not be included. The resulting dump file is not a tar file, it's a dump file.

You use the -L option when the filesystem is mounted, normally you would dump unmounted filesystems. Since it's mounted the data on it may change while dumping hence the term "live".
 
I would suggest using rdiff-backup to back-up your system. Then, use a separate script to mysqldump your databases and use rdiff-backup on those .sql files as well.

This will allow you to store increments and you can even roll back your databases if you hose your data.

Using dump will not get your databases properly as the files will likely be "open" you'll have corrupted, unsafe backups of your mysql database files directly (binary).
 
I'm still not sure how to approach this. I thought I could take a snapshot of the entire system and use this to backup my entire machine?

I also thought that by using the dump -L option that I could backup a live (mounted?) live system (including MySQL)?

Am I approaching this the wrong way? I just want to be able to backup everything in its entirety so that should the machine "die" I have a way to restore the entire system from the backed up file it creates.
 
Using dump will make a dump file that contains all of the files in your file system. Your command should look something like this:

dump -0aLf machinename-date.tar /dev/mirror/RootMirror4s1a

You will need to run the dump command for each file system you have data on (use df -h to see all the currently mounted file systems).

Regarding MySQL, you would get the files backed up but they may not be in a consistent state if your writing data to them. Check out the MySQL Reference Manual -- it recommends making sure you lock the tables before backing up. You could also shut down MySQL before doing the backup and then start it back up after your done. As with other recommendations, I use the mysqldump command to create daily snapshots of my databases. While slightly more effort to restore fully, it provides some protection against a database/table getting corrupt or losing data (ie human error or otherwise).

Make sure whatever backup you use is safe. Generally this requires the backup to be usable (test it!) and offsite (ie .. making backups to a mirror or external drive on a single computer will not cut it if the computer is stolen)
 
cerulean said:
Using dump will make a dump file that contains all of the files in your file system. Your command should look something like this:

dump -0aLf machinename-date.tar /dev/mirror/RootMirror4s1a

You will need to run the dump command for each file system you have data on (use df -h to see all the currently mounted file systems).

Regarding MySQL, you would get the files backed up but they may not be in a consistent state if your writing data to them. Check out the MySQL Reference Manual -- it recommends making sure you lock the tables before backing up. You could also shut down MySQL before doing the backup and then start it back up after your done. As with other recommendations, I use the mysqldump command to create daily snapshots of my databases. While slightly more effort to restore fully, it provides some protection against a database/table getting corrupt or losing data (ie human error or otherwise).

Make sure whatever backup you use is safe. Generally this requires the backup to be usable (test it!) and offsite (ie .. making backups to a mirror or external drive on a single computer will not cut it if the computer is stolen)
Click to expand...

Thank you!

Heres what I have done:

Code: 
/usr/local/etc/rc.d/mysql-server stop

To stop the MySQL service. Then I run the dump command:
Code: 
dump -0aLf machinename-date.tar /dev/mirror/RootMirror4s1a

This is the only file system I have that is present on the system that needs backing up. The only other one listed was "devfs" which I ignored (not even sure what it is).

After the dump completed I restarted the MySQL service. Does this mean I now have a COMPLETE backup of the system including all my databases (since I stopped the MySQL service before running dump)?

One other thing, how do I view what the contents of my tar file are that is created with the dump command above?

I know how to do a restore but not sure how to "see" whats in the tar file!

Many thanks.
 
Everything you wrote sounds good. The dump file is not a tar file.. you will need to use restore (man restore) to restore a dump file (it has an interactive mode so you can select individual files).
 
Is there a way to just look into the dump file without doing a restore?

On another note. Lets say my entire system fails and I reinstall FreeBSD on another machine. Can I restore the entire contents of my dump file onto the new machine? Will the new machine be identical to the old machine that failed?
 
xy16644 said:
Is there a way to just look into the dump file without doing a restore?

On another note. Lets say my entire system fails and I reinstall FreeBSD on another machine. Can I restore the entire contents of my dump file onto the new machine? Will the new machine be identical to the old machine that failed?
Click to expand...

You can see the contents of the dump file with the '-t' option to restore().

If you restore the contents of your dump file onto the new machine, there is no need to install FreeBSD on it first. You'll need to boot FreeBSD to be able to run restore at all, but you can do that from removable media (e.g., a CD).
 
Lowell said:
You can see the contents of the dump file with the '-t' option to restore().

If you restore the contents of your dump file onto the new machine, there is no need to install FreeBSD on it first. You'll need to boot FreeBSD to be able to run restore at all, but you can do that from removable media (e.g., a CD).
Click to expand...

Thanks for the reply! I am really interested in your second comment about doing a full system restore. Can you give a bit more details about how to do a full system restore?

Do you boot off the FreeBSD CD and then run the restore command and point it to your dump file? :)
 
xy16644 said:
Thanks for the reply! I am really interested in your second comment about doing a full system restore. Can you give a bit more details about how to do a full system restore?
Click to expand...

Have you read the (multiple) descriptions of related procedures in the FreeBSD Handbook? If so, can you be more specific about what you want more explanation of?

Do you boot off the FreeBSD CD and then run the restore command and point it to your dump file? :)
Click to expand...

Sure. In practice I haven't done that in years, because a dead disk has usually been a good excuse for an extensive upgrade of the base system, but I'm prepared to (quickly) get back up from backups (including incrementals) to exactly where I was at the time of the last backup. I practice this occasionally on spare machines; if you haven't tried your restore procedure, you can't be sure you really have backups.

Note that dump()(8) only works on filesystems, so many people arrange their systems for convenience of backups. I also recommend more than one form of backup, because backups have more than one purpose.
 
You must log in or register to reply here.
Back
Top