Best procedure for full backup of live system
jerrymc at msu.edu
Thu Oct 15 14:40:36 UTC 2009
On Wed, Oct 14, 2009 at 08:42:47PM -0700, Nerius Landys wrote:
> My server is increasingly having important work stored on it, and I
> need to start taking backups of a lot of directories, especially
> /home, /opt, /etc, /usr/local/etc, and maybe others. The ideal backup
> (and what I've done in the past) is to take a full low-level dd image
> of the disk while the system is down (this is easy to do in a
> situation where you have dual boot). Or, since the output of dd would
> take up tons of space and would only be usable on an identical hard
> drive, use "dump" to take the backup while the machine is turned off
> (again easy to do on a dual boot). But now, I cannot bring down the
> machine. My plan is to do a tar gzip of / on the fly, and pipe that
> to ssh (remote machine). However, the system is live, and files will
> be in the progress of changing.
> My question is, what is the recommended procedure of taking a full
> backup on a live system? Ideally, if my hard drive were to crash, I
> would like to have such a backup so as to make it possible to copy
> over the entire backup to a new identical harddrive without doing any
> reinstall or configuration. Should I use tar/gzip? dump? What exact
> command should I use? I guess I'll back up all of / including system
> files, because there is not too much data. I will be piping the
> output to ssh.
Use dump(8) to back up each filesystem that is important and that
cannot be easily recreated (such as by reinstalling). Don't bother
with any of that tar and dd stuff as long as the dump will be read
on a similar system (FreeBSD). Use the -L switch for making a dump
on a live filesystem. It forces a snapshot so files are not in
transition while the backup is done - or rather, makes it so the
backup is of an intact image.
Your big issue then is where to write the dump, how often to do it
and how many copies you want to keep of it.
You can do full dumps and dumps of just what has changed since the
last time a file was dumped. I call those full dumps and change
dumps. The documentation referrs to them as level 0 for full dump
and level 1-9 as the change dumps. The man pages give a complicated
scheme for managing full and change dumps. Probably most people
really need only a level 0 and a level 1, maybe a level 2.
Basically the point of the change dumps is to make smaller backup
images which takes less time and less media. You only make the
full dump (level 0) once every week or every month - whatever your
needs are. Then, in between you only dump the files that have
changed since the last full dump. If that change dump file gets
too big as well, then you jump to the next level on change dump.
So, you do a level 0, then, the next day a level 1. If it is
small (meaning only a relatively few files have changed) then the
third day you still make a level 1. If the level 1 dump is now
real big (meaning a lot of files changed) then on day 4 you go to
a level 2 dump, etc. It is probably a good idea to regularize the
process of choosing levels. That is why the man page has such a
complicated scheme that covers all conditions. But, as I indicated,
most people with a personal or office/department level server often
need only a need the regular full (level 0) dump, plus a daily level 1 dump
in between the full dumps. In fact, I have some servers that are
small enough that I just make level 0 dumps each time.
Now, if you have a big system with lots of new files and changed files
all the time, then you will have to organize your dumps in a more
sophisticated manner. Generally, level 0 dumps take whatever amount
of media they need to contain the whole filesystem. Then, for the
change dumps (level 1..9) you hope to keep then to only one unit of
media. If a change dump goes over one unit of media, then you move
up a level the next time. The same goes for if the change dump
starts to take a lot of extra time.
As for media, it can be to an external disk, a tape or over the
net to some big storage space. Try to spread it out so that each
set of dumps is not on the same physical media as other ones - eg
rotate your media.
> freebsd-questions at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
More information about the freebsd-questions