Jump to content

Maser

Members
  • Posts

    2,054
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by Maser

  1. Retrospect.app: accepted source=Developer ID origin=Developer ID Application: Retrospect, Inc.
  2. Did you try Retrospect 11.0.1? I didn't get anything similar from that version if I run "spctl -a Retrospect.app" - Steve
  3. I don't know if this is a bug or not (as I've only ever manually added static-DHCP-assigned clients by IP address/hostname...)
  4. I meant to update this with a Windows 8.1 client test. Same issue: Restores from my engine machine to a Windows 8.1 64 client — are also running at around 12.7M/min (about 1M/min faster than restoring to my Mac clients.) Still much, much too slow.
  5. Retrospect 11.0.1 (with client) 11.0.0 (191). Both client and engine computers are now running 10.9.4. I have tried a client running 10.10 DP3, but there is no difference in speed. Have not tried a Windows 8.1 client (yet), but will tomorrow and update this post/thread accordingly...
  6. I have not seen a similar problem after upgrading my clients/engine machine to 10.9.4 -- but I add all my clients via hostname (rather than by discovery). How did you add your clients to the engine?
  7. Yeah, I find that you can still back up to a catalog where grooming fails with a "rebuild catalog" message in the log. You should still rebuild the catalog, though (not just "repair" it) before you trying grooming again.
  8. I asked this once and I believe the answer is that it will keep the "month" backup forever as long as you have the disk space for it (or your media set doesn't run out of it's defined space). If the automatic grooming has to run because of running out of space, then the oldest month is groomed out, etc...
  9. So, having done grooming with Retrospect for years now, I can answer some of this from my experience: 1) If the status is updating at all -- it's working. 2) In general, as long as the status is not indicating that it's actually *doing the grooming of the files* ("Matching" is not grooming), you can stop the process without compromising integrity. However, the general suggestion for a media set if you unexpectedly stop a groom is to rebuild the catalog before using the media set again. 3) As to your "how long might it take to groom 800G" -- it all depends on (A) the number of files, backups *and sources* in the media set, ( what your groom settings are and © how fast the CPU is of your "engine" computer. You could have 800 1G files in your media set over 20 backups of one source, but your groom settings are just to keep 15 backups and that would probably groom in about 15 minutes (or less). Or you could have 800M files over 1000 backups over 30 sources and you are grooming this to keep 20 backups that will take a *lot* longer to groom. My last real-world example of a groom was that rooming 315G (which was mostly large 4G database files) took 16.5 hours. I can't tell you the size of the media set *prior* to backup, but that media set currently has 3.2M files in it, uses 1.5TB of disk space and my groom settings are to keep 90 backups of two Mac OSX 10.8.5 file servers (the entire server). Another media set I have that just backs up *one* 10.9.3 server -- but keeps 183 backups -- only groomed out 21G of data the last time I ran it, but that took 28 hours to run. That media set has 3.3M files in it and is 915G in size. This is an example of a media set with twice as many backups, but essentially the same number of files in the media set. My engine computer is a 2.5Ghz i5 Mac Mini with 8G RAM. CPU speed -- above all else -- factors into grooming speeds with everything else being the same.
  10. The only way I've figured out how to do this is to make a new, empty media set and do a backup to that. That'll tell you how much would be backed up with a "clean" backup, but there's no really easy way -- short of running a "copy" backup script -- to tell how much *total* data has been backed up by any one client that I've been able to find out.
  11. Yeah, I have this issue on *one* of my Windows 8.x clients (though mine is a "T-8: VssWSnapVolume: DoSnapshotSet failed" error.) I was pointed to this: http://www.retrospect.com/en/support/kb/3045-there-is-insufficient-storage-space-to-complete-the-operation-and-3405-can-backup-system-state What I'm not sure about is why this one client generated a "System Reserved" partition with less free space on it than my other clients. (I'm just ignoring this for now...)
  12. I've found that proactive backup times for always-on computer "drift" (and have done this forever -- and drift is worse if you have multiple proactive backup scripts running concurrently). I can set a server to backup at 2:00 a.m. on Monday (one backup every day) and by the end of the week, it will have drifted to starting the backup on the next Monday to 3:30 a.m. If you want it to *always* trigger at a specific time -- don't use a Proactive script. Proactive scripts are great for laptops and things that aren't on 24x7
  13. I don't have Bento, but have FileMaker and every time you touch a fileMaker database, the modification date changes. Are you sure the actual Bento database is really stored in the users (hidden) ~/Library folder and not something more visible?
  14. Retrospect 11.0.1 is out and purports to have a fix for this (according to the release notes...)
  15. I saw this problem as well this weekend when running a groom.
  16. Yeah, I hit the out-of-memory error this weekend when grooming a media set. Oddly, I did not hit this problem when grooming a different media set the week before...
  17. I have no showstoppers with 11.0 at this point. However, 10.5 was pretty rock-solid for me in how I used it. The only "known issue" that is most irritating to me at this point is the fact that manually removing a Past Backup does not update the list to reflect the removal unless you stop and restart the console. That's a new bug in 11.0 and I hope that one is fixed quickly.
  18. So, I've been running 10.5 with Mavericks without any serious problems. I have not attempted a "full disk recovery" as I only really back up "/Users" on the machines I back up. As far as RetroISA scanning external drives goes -- yes, that's a PITA, but if they are the same external drives, you can modify a file so that RetroISA will skip those volumes only.
  19. Do you mean say you have a proactive script set to back something up every 24 hours and it's already backed up something today, but you want to run it again today? If so, just click on the activity for "tomorrow" and then click on "schedule". That sets the time to right now. When you click on the "schedule" button, the proactive script should start running because the activity is set to ASAP at that point.
  20. I've seen different behavior here with the borked 3.7 ARD client, so YMMV, but... 1) In general, turning the GUI firewall off seems to get around the problem, but sometimes it doesn't. This is hit-and-miss. Basically if the GUI for the Firewall shows that "screensharingd" is "blocked" -- then you have a problem. 2) The only "fix" for this that has worked here is to replace (on 10.8.5) the /System/Library/CoreServices/RemoteManagement folder with the same one from a machine with the ARD 3.6.2 client still installed and then reboot. And then edit the Firewall GUI to remove that "screensharingd" block. But, based on your comments about Retrospect working after a restart and having the FW off on the engine machine -- this is probably not your problem.
  21. By off chance -- did you install the Apple Remote Desktop 3.7 client on this machine? There's a huge bug in that client that affects the Mac OS firewall -- and (in my testing) not just for ARD -- but also for other apps that you wouldn't expect. (I installed this on my 10.9 machine that runs the Retro 10.5 engine and not only could I no longer control that computer with ARD, but *Retrospect* would not back up any clients either with the borked firewall enabled!)
  22. The odd thing -- I tried another media set and had weirder results... I restored one database file (5G in size) from this other media set -- restore speed was 1.2G/min. I then restored a mysql instance from /usr/local/<mysql directory> -- 180M -- and the restore speed was back down to 12M/min. Something is not right here...
×
×
  • Create New...