Thanks! This was exactly the sort of informed advice I was looking
for. Much appreciated.
-------------
Marc W. Davis
Systems Administration Associate
Cowles Library
Drake University
(515) 271- 1934Quoting Eric Searcy <[EMAIL PROTECTED]>:
On Apr 18, 2007, at 10:27 AM, Marc W. Davis wrote:
Hello.
Two questions here.
(1) relating to "file vanished on sender"
(2) looking for wise counsel on deciding what needs to be backed up
(1) on a --init, I got three "file has vanished" errors. They
were session id files from php and postgres. I inferred from
reading
earlier traffic on the list that these errors could be ignored.
Are there other implications to having the error that I'm missing?
Yes, you can ignore those, that's a standard rsync error that means
that a file existed when the sync started and it scanned for changed
files, but by the time it came to back up that file, it wasn't there
anymore. This usually happens with small files like lockfiles and
sessions that come and go rapidly. If it is a consistent issue that a
specific group of session files vanish and cause you to get emailed on
a otherwise successful backup, you may want to exclude them--only to
help the email issue, as said there isn't anything wrong with having
the errors.
(2) one box I want to backup is our web server (with mysql, php,
tomcat) running. I'd like to make as comprehensive a backup as
possible -- looking toward the idea of being able to rebuild to
new or repaired hardware should disaster hit the server box.
I backed up from / excluding /proc, /media, /mnt, & /var/tmp
from the backup. I'd like to know from those who are more
experienced and knowledgeable than I what you think of that
scheme. Leaving
something important out? Wrong place to ask the question?
Thanks.
Marc
Two thoughts: one, yes you should be able to pull the whole
filesystem, less the folders that you mentioned, and still be able to
recover by strictly copying a backup onto the host. However, if you
are excluding /proc/ (the folder), and not /proc/* (everything under
it), when you copy back you won't have the needed folder for the mount
point and will have to create it manually. Same thing for the other
directories. Also, depending on your system and kernel, you should
possibly exclude /sys/, it's like proc.
Thought two: you say you're running mysql. Only doing a bit-by-bit
copy (like an rsync) of the db location /var/lib/mysql (or wherever it
is) can have drastic consequences because the DB backup can be
corrupted. This is because the DB might be in the middle of a write
when you pulled it. Same thing for other systems that use DB
backends, like subversion and openldap. Rsync backups don't hurt (it
won't corrupt the running DB), but it doesn't replace a mysqldump or
mysqlhotcopy. I like dumping the DB to another spot on the same
filesystem--it will be faster than a remote pull, and the dump
directory will be safe for Dirvish to back up.
--
Eric Searcy
OSU Open Source Lab
_______________________________________________
Dirvish mailing list
[email protected]
http://www.dirvish.org/mailman/listinfo/dirvish
