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
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Dirvish mailing list [email protected] http://www.dirvish.org/mailman/listinfo/dirvish
