Jump to content

Maser

Members
  • Posts

    2,054
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by Maser

  1. So (to confirm), you never -- after you did all your configuration -- shut down the engine via the system preference -- to force any flush/write to the config80.dat file? I'm wondering if you -- somehow -- locked the config80.dat file from being writable? If you still have the file in /library/application support/retrospect -- can you do an "ls -la" in Terminal to show the permissions on the file? Does it look like this: -rwxr-xr-x 1 root admin 971628 Dec 21 16:49 Config80.bak -rwxr-xr-x@ 1 admin staff 971628 Dec 21 16:49 Config80.dat (this is from an "engine running" listing...) (the "root/admin" perms on the .bak file might be something different -- but the rwx... perms should be the same...)
  2. I'm not going to try to convince you to stick Retrospect -- you've clearly had a lot of problems with it that others aren't seeing as much of (like your DHCP problem and some clear power problem that worries you enough that you keep force-powering off your backup server...) However, whatever you move to, I would strongly recommend you get a UPS to run your backup system on -- if your backup is important to your company/department/unit, there's no excuse for not having a UPS on the backup. (I'm not sure what you meant by "never wrote to the config file", though -- at what point did it not write?)
  3. I had a similar problem recently -- I tried to restore a bootable copy of my server to an external drive and Retrospect would crash each time it tried to restore a file within the Apple "Address Book" application package. No idea why. Retro Engineers thought that maybe there was corruption in the initial backup of the file. I was able to work around this by backing up my server to a new media set and then copying past backups from the old media set to the new media set (as "Address Book" hadn't changed) and then I could restore the snapshot from the previous backups. Weird. Anyway... Can you restore *anything* from your backups? Or are you crashing only on attempting to restore that one particular folder? What if you attempt to restore just some of the files *within* the folder and not select the enclosing folder for restore?
  4. Yeah, I think the "backup server" media issue really was initially a 10.5 issue and still was there in 10.6 (I think). Never fixed by EMC at the time, either. I think if you treat 6.1 as something that will back up "the file" and don't worry about "the attributes on the file" -- you'll probably be OK. But don't necessarily count on it to restore a completely bootable 10.6 client, either. YMMV. You should keep testing this to see what does/doesn't work if you want to stick with 6.1.
  5. Once you use 6.1 under 10.6, you'll see the bugs in the program. Every time I've set it up to test something, I'm reminded of the (admittedly few) things that don't work quite right. Or the things that outright failed (such as the inexplicable "media" issues running Proactive backups that was never fixed...) But, I think as long as you aren't using it with the intent of being able to restore a *bootable* system you backup -- it can be made to work.
  6. There should be nothing (really) stopping you from using the exact same IP address you are pulling via dynamic DHCP and entering it as a static IP address for all of the 2 minutes it would take you to reboot your computer to see if this works. It would be extremely unlikely that somebody else is going to boot up and attempt to grab that "pool" IP address. Worst case -- ask your DHCP administrator what the range of addresses are that are configured and use something at the tail end of the range that is currently not in use and use that for 5 minutes. All you are trying to determine is if you have the same problem if you have a static IP address assigned to your computer. If so -- there's a bug elsewhere in Retrospect (or a bug specifically with your setup as the majority of us do not see this problem...) If *not*, then this would be a good discussion to have with your DHCP administrator to see if there's something keeping you from being assigned an IP address immediately at boot time.
  7. So, if you want a history -- do a daily backup of the files with Retrospect. I have almost a year of "config80.dat" files in a media set and it takes less than 500M to store this. If you are concerned about the time it takes to revert, just make a *clean* config80.dat file with the license in it and the already-located config80.dat backup media set in it only. And store that version of config80.dat somewhere safe. That way, you can just swap that out if necessary to retrieve something you've already backed up without spending a whole lot of time on it. I certainly appreciate the need to consider alternate ways to access the files, but you can (relatively) easily do it with the tools provided.
  8. I think the point we are trying to make is to see if the problem goes away if you enter static information in for the IP address for the engine computer. You should be able to test this in all of 5 minutes using whatever dynamic IP address your machine is currently receiving.
  9. Maybe the time on your computer is off? Or your automator script grabbed the wrong file and put it in the wrong folder (maybe it's running in reverse?) I keep my "application support\retrospect" folder open 100% of the time on my 10.6.5-running Mini. I've never seen the .dat file have an earlier time stamp than the .bak file.
  10. Huh -- opening/closing the Console preferences worked here. That's a good tip! Creating a new temporary script -- and then deleting it -- seems to force an update to the config80.dat file, too. (EDIT: I take that back -- the creating/deleting of a new script doesn't seem consistent)
  11. What if you manually put in that IP address and reboot? Do you have the same startup problems?
  12. So, you still can't scan the C: drive correctly (I'm assuming you are booting from the C: drive when you do this...) You might try to isolate what causes the error by creating a series of "Favorite Folders" on the C: and scanning each one. If you can isolate a specific file that causes the error, I'm sure the engineers would want to know about this.
  13. So, I asked them about this. Turns out changes made with the console are stored in RAM and then flushed to config80.dat at specific intervals (such as starting a script or stopping the engine). This could explain why you are corrupting your file when you power your engine machine off -- maybe you are doing this right when the file would be updating? Whether or not this is an industry-standard way to do things, I don't know. I'm guessing there's a technical reason they don't automatically update the config80.dat file every time that there is a modification to something...
  14. I back up all of our Windows 7 clients without issue. When are you getting that error? When you add the client? During the backup scan? During the actual *backup*?
  15. Yeah -- that's why I'd be curious to see the system.log startup entries from somebody having this problem. Maybe the people having this problem aren't getting their IP address fast enough from their DHCP server? (I'm assuming it's only DHCP serving machines that have this problem? Though *my* backup server is getting it's *static* address assigned via DHCP -- are the machines having this problem getting non-static DHCP addresses?)
  16. The reason I said "every 90 minutes" is that appears how often *my* config80.bak file updates itself (as I run Proactive scripts 24/7). If you back up the config files to their own media set, if you have a crash, it's (relatively) easy to reenter the serial number, locate *only* this set and restore the last file you backed up. Then quit the engine, replace the files, restart the engine and you are back in business. I've had to do that a few times while testing stuff. It's not as easy as having a Finder copy, but it works. Unless you are making changes to the configuration hourly (and, in which case, you might just as well make a Finder copy of the files), there's likely no significant reason a daily backup of the files done at midnight (or whenever) wouldn't suffice. I think you've hit the nail on the head about why the files get corrupted. The config80.dat file changes *appear* to be cached and only written to the file when there are no other activities going on. Frequently, this is quick, but it's not always quick. I remember asking them waay back when about when does the *bak* file get updated and they weren't able to tell me (as it wasn't an automatic interval -- for me, it's about every 90 minutes...)
  17. While it's nowhere near as easy to determine as Retrospect 6... if you walk through the Backup wizard, at the point where you'd actually start the backup, you can "Preview" the backup. The resulting preview would show you the files that would be backed up. So you could assume that the rest of the files *have* been backed up (assuming no rules are in play that would limit what you see in the Preview...)
  18. I haven't played a lot with Automator, but how does it defined "modified" -- just by changing the time stamp of the file? Or do you have to modify the contents? That said... Why would you need to get a copy of the file every 90 minutes or so? Why not just once a day with a backup script copying the files to a media set?
  19. If you *power off* the computer -- not shut down the engine -- you will likely corrupt the "config80.dat" file. If the config80.dat file is corrupt, the program reads from the "config80.bak" file -- which explains why your client you added was missing (the .bak file hadn't updated yet.) For your second test, it was more likely that either (A) nothing was writing to the config80.dat file so it didn't get corrupt or ( the .bak file was updated before you powered it off. Either way -- you shouldn't just "power off" your computer willy-nilly!
  20. Right -- when you use the Restore Wizard you can set it (if you want) to search through *all* media sets -- but it *will* take a long time (depending on how many files are in your media set...)
  21. To restore the file: 1) stop the engine 2) delete the bad config80.dat *and* config80.bak files. 3) replace with a copy of your saved "config80.dat" file 4) restart the engine. I might suggest you keep the console open and watch your scripts in action to see if you can find what activity is causing the engine to crash. You might have a client with a bad file/directory on it, or it might be something completely different. And, no, there's no apparent way to "locate" more than one media set at a time because you could store the media set catalogs in any number of places -- each could have their own folder, for example.
  22. When things "vanish", it usually means the engine has crashed (and usually crashed more than once) and corrupted your "\Library\Application Support\Retrospect\config80.dat" file that contains everything the engine needs to operate. What you probably should do (if you aren't doing) is back up that file when you make significant configuration changes to your system. That way you can easily restore that file and be back in business. However, if this has been happening "a few times in the last couple of weeks" -- you probably need to try to figure out what is causing the engine to crash so frequently before moving forward.
  23. You can do one of two things: 1) You can browse "Past Backups" -- which will show you highlights of the files backed up. If you aren't using Groom settings, though, you don't see all the past backups. This is (for me) usually faster if I'm looking for something I know about on a specific date of backup. 2) You walk through the Restore Wizard and "preview" the results before you restore them. If you don't need to restore anything at that point -- you don't have to. And, yes, everybody agrees the method for seeing what was backed up is in *no way* as good as it was in Retrospect 6.
  24. You certainly can backup multiple partitions from a source -- that's not a problem. You can't restore all volumes "at once", though -- I believe you can only restore one volume at a time (assuming you lost both volumes...) Your second question is more interesting -- whether or not you can backup a Bootcamp volume while the client is booted in OSX and then be able to restore the Bootcamp volume and have it be bootable after a restore. Somebody has probably tried that sometime -- I'd be curious if that works. (The alternative of booting into the Bootcamp partition and backing up that volume as it's own client *does* work. as it's just a Windows "machine" at that point.)
  25. The other thing you might try -- based on the original question: What if you stop the engine *before* you reconnect the "disconnected" drive? And then restart the engine while the drive is connected? Is the Media Set "linked" correctly then?
×
×
  • Create New...