Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Maser

  1. I don't use it, so I can't say how well it works, but there's an "Enable Wake-on-LAN" option for the Sources. It's not on by default. You might try that. But I don't know if it would wake a laptop where the laptop is asleep because the user closed the lid (for example).
  2. A lot of things are possible, but the most common thing would be the laptop went off the network (or to sleep) during the backup. If that's not the case (and you can confirm that), I'd watch the backup run and see *where* the -519 is occurring -- it might be hitting some "bad" file and that's causing the client to disconnect.
  3. I honestly have no experience with a Drobo, so I can't tell you if there are issues with the file system on it or not. What you *might* try is seeing if you can rebuild a new media set for each set of 1000 files. If so, then maybe do a "copy media set" to put them all into one new set?
  4. Logging like this is in the basic "operations_log.utx" file. I have a couple of thoughts: How many .rdb files are within your media set? Are the last three 6909-6911? Or do you have ones after that? You might consider just moving those 3 .rdb files out and recatalogging again. If you don't need the data in them (based on the dates on the files), then just trash them. If you *do* need the data on them, I believe you could try moving them to their own folder and attempting to recatalog a new media set just containing those files. I had an error once after I groomed a media set where the log indicated an error in the set. Any subsequent recatalogging would continue to generate an error. Eventually, I turned on logging, found the "bad" file -- which was in the middle of all the .rdb files -- and just trashed it and recatalogged again without issue. It depends on your data retention policy as to whether you feel comfortable doing this or not.
  5. You never indicated above that you tried to rebuild the catalog with advanced logging on (or that you actually ever *had* a successful catalog rebuild.) I'd still recommend you turn on the advanced logging and rebuild again and find out where the problem is. Worse case? The logging will tell you where things start "looping" and you can just delete the possibly bad .rdb file, then recatalog again without it -- you'll just have lost the files backed up within that one .rdb file.
  6. The rules I needed to make -- work. I'm not sure what more I can tell you about them. IMO, starting clean with 8.2 is better than trying to work with something that wasn't working properly in 8.0 or 8.1 I do agree there are some oddities with rules (setting some things seem to change unexpectedly, but I'm not sure how much of that is to force you into the logic you need to follow.) If you have a rule question, I can try to answer how I do it (or how I might do it).
  7. I have no problems with 8.2. I rely on it fully at this point. But I don't use tape. I don't backup to a NAS or Drobo. And I don't have a server with an Apple RAID card hosting the engine computer. I back up about 60 10.6.4 and Windows 7 clients -- most laptops -- (and 3 10.6.4 server machines) using 8 concurrent proactive scripts to an External firewire RAID drive and I groom a media set weekly (and groom other media sets on a once-every-5-weeks schedule.) I use custom rules and no encryption on my media sets. For me, it's working as I expect it to work (with the exception of some esoteric bugs I've recently discovered/verified). Some things could be faster (and a *lot* should be rewritten -- I'm talking to *you* Roxio about improving the reporting/browsing of what actually gets backed up -- , but I'm satisfied with the product at this point to do what I need it to: back up everything daily and easily restore files when I need to recover them. But, I am not you. I can only say "try the free demo and see if it works for you." It would be remiss of anybody to imply you shouldn't also try other products and buy them if they work better for you. Retrospect 8 is basically a brand new product with an old name. You shouldn't think of it as an "upgrade" to Retrospect 6. I would never revert back to Retrospect 6 at this point. It would be impossible to function without the ability to do concurrent backup/restore -- especially with all the laptops I have in my area. Grooming is just icing on the cake. Those two functions alone -- and they work -- make me overlook some of the (significant) shortcomings.
  8. Why not try Retrospect 8? You get 30 days with a "trial" license, IIRC... If you don't like it, evaluate something else? (However, if you are having some kind of network problems, Retro 8 may not work any better than Retro 6 does...)
  9. Whoops -- lost track of the thread. Sorry about that...
  10. It's unprotected (or should be) until it's backed up. Does it not change after you delete/readd/rebackup?
  11. Well, sure, the distributor of CrashPlan Pro is going to say it's better than anything else. Are you surprised? (That's not to say it's not a good product or that I'm looking to turn this thread into a debate about other products, but you have to take the presentation as it's presented -- a sales pitch.) And, from what I can tell, CP doesn't support Tape drives at all (right?) -- so it wouldn't meet your needs.
  12. The only source of mine that is unprotected is the firewire drive that contains my media sets -- so I don't see this. What happens if you remove and readd the clients (and then readd them to your backup scripts?) Do they stay "unprotected" after the backup. It sounds like a bug, but possibly only fixable if you can reproduce it.
  13. Yes -- I've seen that one other time ages ago. I don't remember the exact circumstances, but something I did when testing things rebuilt the catalog automatically before actually running the scripted backup. Good to know that still works.
  14. If you use the Backup wizard -- it's at the "Backup Summary" page -- where you would click "Start Now". On the line showing the source(s)
  15. If you are scheduling a backup, you can't schedule for a past time. Meaning if it's now 3:00 p.m., you can't schedule a daily backup starting *today* at 1:00 p.m.. You have to specify that schedule to start *tomorrow*.
  16. and here's a subsequent backup (nothing changed): + Normal backup using Backup Assistant - 10/15/10 11:16 AM at 10/15/10 (Activity Thread 1) To Media Set DEV... - 10/15/10 11:37:24 AM: Copying Developer 10/15/10 11:37:24 AM: No files need to be copied 10/15/10 11:37:37 AM: Snapshot stored, 13.4 MB 10/15/10 11:37:39 AM: Comparing Developer 10/15/10 11:37:39 AM: Execution completed successfully Duration: 00:00:15 (00:00:13 idle/loading/preparing)
  17. Weird. I have xCode 3.2.4 on my machine (in all honesty, I can't remember if I had a version of xCode on my machine prior to moving from 10.5 to 10.6) I have the engine running on my machine (3Ghz intel core 2 duo iMac). I set "Developer" up as a favorite folder. I made a new media set (stored on my internal hard disk). I did a backup of the FF using the wizard. It went quickly as expected and did not have any issues with building a snapshot (I used the backup wizard, so this had a verification step I normally wouldn't use...): + Normal backup using Backup Assistant - 10/15/10 11:16 AM at 10/15/10 (Activity Thread 1) To Media Set DEV... - 10/15/10 11:16:15 AM: Copying Developer 10/15/10 11:21:09 AM: Snapshot stored, 13.4 MB 10/15/10 11:21:12 AM: Comparing Developer 10/15/10 11:23:47 AM: Execution completed successfully Completed: 49802 files, 1.6 GB Performance: 458.2 MB/minute (354.1 copy, 651.8 compare) Duration: 00:07:31 (00:00:16 idle/loading/preparing) Maybe it would be worth uninstalling xCode and reinstalling it with the current version (3.2.2 is on ADC, but Software Update brings this to 3.2.4) to see if that makes any difference?
  18. Was this the *only* version of xCode you ever had installed on that machine? Or had you upgraded from previous versions in the past? /Developer must have some hard links in some folder that cause the extra snapshot time. I suppose the next step would be to make favorite folders *within* /Developer to figure out exactly what subfolder creates this problem and go from there.
  19. I'd try rebuilding that catalog file again with advanced logging on: Edit the "Retro.ini" file inside the RetrospectEngine.bundle so that the line says: SetDevicesLogging=7 Then stop/restart the engine. The next time you rebuild a catalog, it'll flood the log with a lot of step-by-step detail about the process of the catalog rebuild. That will tell you specifically if it's looping or not.
  20. Depending on how you "rebuilt" the user account -- backing up all the data all over again may be expected. If the extended attributes/metadata of the files are now *different* -- Retrospect will see them as different files and back them up again. I have no idea if BRU does the same level of file comparison for matching purposes or not. One would think so (at least I'd hope so), so things may not be any different with another product.
  21. Unfortunately, there seem to be a number of posts about users with NAS drives having issues that people with other types of drives as backup media are *not* having. But, also unfortunately, nobody has been able to post anything to any of the forums reproducing a specific set of problems with specific NAS drives (formatting, methods of connection/disconnection what have you...) I'm sure if somebody could give a specific reproducible case, the Engineers would be all over this...
  22. Because it sounds like it's stopping on scanning the drive at the same point now, you might have some new funky file/folder that Retrospect is barfing on and you'll have to isolate this. The easiest (?) way of isolating this would be to set up a series of "Favorite Folders" and just keep scanning those until you find the "bad" folder, etc...
  23. ? If you walk through the Backup Wizard, you'll see where the Preview button is.
  24. If you want to just back up a single folder, the best option is to make that a "Favorite Folder" for the Source. Otherwise, you have to scan the entire drive.
  25. If you "reorganize", you'll probably have to rebuild the catalog file again. if you have the free disk space, I'd just do a "copy media set" to clean this up.
  • Create New...