PDA

View Full Version : Scheduled Smart-Update without logging in works at first but fails on later


mlerch
03-07-2007, 10:17 AM
Please allow me to explain real quick what I did. Now this probably has been talked about, and if so please move my post under such existing topic.

Here is what I did.
- Platform: OS X 10.3.9 Server
- Logged in as root user
- Installed and launched SuperDuper!
- Selected to Smart-Update drive B (250GB backup drive) from drive A (80 GB startup drive)
- Selected to run a script before doing the clone which basically creates an archived MySQL backup
- Created a schedule to run nightly at 10:30pm
- Logged out of the system

Here is what happens:

- The first scheduled backup works perfectly. Clone created (but have not tried to boot from it since this is a production server and it is co-located and I really don't want to reboot from the backup drive if I don't have to).

- The second and sub-sequent backups seem to work also like clockwork.

- Then it happens - one morning I will log in and check to see that SuperDuper couldn't do a Smart-Update due to the fact that there is not enough room on the destination drive (please note that the clone was exactly that - a clone - the night before)

The Startup disc has about 30 GB space left. The backup drive I am cloning to is 250GB large, so at the most I would assume that even if the startup disc is completely full, and let's say I renamed a lot of large folders on the startup drive, I would need at the very most 160GB of free space on the backup drive (since the startup drive has a capacity of 80GB and you are doing updates in one pass - as explained in previous posts).

- In any case, the backup drive now only shows that there are 4KB of space left
- When I try to perform an erase and install, it will fail - get another error message
- So I open Disk Utility and try to erase the backup drive - once again, I get an error message stating that the backup drive can't be umounted.
- Next step is for me to reboot the server.
- After reboot I open Disk Utility again, erase the backup drive - no problem.
- Then I have to open SuperDuper under Root again, delete the old schedule, set up a new Smart-Update schedule with the new backup drive, save the changes to the script, Quick SuperDuper and log out. Now we are starting again with a few successful cloning processes until everything repeats itself.

-> Backup Drive full -> can't erase and update -> can't unmount -> can't re-format -> have to reboot -> blah, blah, blah


I did read in the User Manual something that a corrupt file could cause this to happen, or if the drive that is being cloned has a lot of activity. Now I really can't turn off the server to do a backup. That wouldn't be an option.

Truthfully, I am already happy that I got it to clone my server's startup drive without anyone needing to be logged in. That was huge for me. But it bothers me that I have this problem, which really makes this whole backup plan unreliable. Yes, I do check the server every morning anyway, but really would like to have a more reliable solution.

Oh yes, tried this whole thing on a friends X Server, also 10.3.9 .... Guess what - same problem!

Any idea why that would be? Please advise. Thank you.

dnanian
03-07-2007, 10:53 AM
Well, I definitely was able to copy my own 10.3.9 server every day for a few years without a problem, so I know it's possible. :)

So. I think it's likely that a file (logfile, database, something) is being written to aggressively when we try to copy it, and that fills the destination. Why that would prevent unmounting I don't know, but it's likely that's why the disk is filling. What file does it say was copied when the drive fills?

mlerch
03-08-2007, 01:05 PM
Thank you for your reply. Right now everything is running the way it should. It may take a few backups for this to happen, but as soon as it happens I will go ahead and save the log output. I'll post it here or send it to you. Again, thank you for your help.

mlerch
03-10-2007, 06:10 PM
Well, I definitely was able to copy my own 10.3.9 server every day for a few years without a problem, so I know it's possible. :)

So. I think it's likely that a file (logfile, database, something) is being written to aggressively when we try to copy it, and that fills the destination. Why that would prevent unmounting I don't know, but it's likely that's why the disk is filling. What file does it say was copied when the drive fills?

Hello,

The error happened again. Please find the cloning log file attached. Looks like it has something to do with a Apache server log. Don't know the specifics though. Oh yes, again I was unable to unmount the volume until I restarted the entire server. does that mean that I have to schedule the back up at a different time? Maybe Apache is doing log file rolling at that time and That's what is causing it? I have no clue. Anyway, please have a look. If there is anything that I could do, like a script that would stop certain processes and then starts them again after cloning.. that would be great. But I wouldn't even know where to start.

dnanian
03-10-2007, 06:16 PM
Yes, as I indicated, this file is being aggressively written as we're backing up. You can either stop apache (apachectrl stop) before your backup, or you could also ignore the whole "logs" folder listed using a custom copy script... see "Excluding files or folders from a backup" in the User's Guide.