Jump to content

Search the Community

Showing results for tags 'proactive'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Announcements, News and Resources
    • Latest News
  • Windows Products-Retrospect
    • Professional
    • Server, SBS and Multi Server
    • Device and Hardware Compatibility-Windows
    • Exchange Server Add-On Support
    • SQL Server Agent
    • Linux, Unix and Netware Clients
    • Express for Windows
    • Product Suggestions-Windows
  • Mac OS X Products-Retrospect
    • Retrospect 9 or higher for Macintosh
    • Retrospect 8 For Macintosh
    • Retrospect 6: Desktop, Workgroup and Server for Mac OS X
    • Device and Hardware Compatibility-Mac OS X
    • Linux Clients
    • Product Suggestions-Mac OS X
  • Macintosh OS 9 and Earlier-Retrospect
    • Express, Desktop, Workgroup and Server for Pre-OS X
    • Device and Hardware Compatibility Pre OS X
  • General Discussion-Retrospect
    • Networking and Clients
    • Strategy, Scripts and General Use
    • Retrospect iPhone App
  • Retrospect 8.x for Mac
  • Retrospect 6.1 for Mac
  • Retrospect 7.7 for Windows
  • Retrospect 7.6 for Windows
  • Retrospect Express
  • General Discussion

Categories

There are no results to display.


Found 11 results

  1. Running trial of v14 Installed new client on remote Mac (public key), defined proactive scripts, sources, media sets. When defining the client all is well; it recognizes the remote Mac and hard drives/folders. I can restore individual files from previous backups back to the client. Dedicated connection between 2 Macs, with manual IP address set on each. Everything works in set-up, but client shows "No network connection". If I force a regular (non-proactive) script to run, the client shows "Protected by Retrospect" while it is running, but as soon as that is complete, the client reverts to "No network connection". While this forced backup is running, status on server shows "Media not available"; as soon as forced backup is complete, goes back to "Status: (Not yet determined)". Is this normal behavior? So far none of my proactive scripts have started - they all show a status of "(Not yet determined)". On-demand features show Unavailable as well.
  2. The default time window for Proactive backup scripts is 00:00 to 00:00 i.e. midnight to midnight the next day and Retrospect server specifically treats this as the beginning of one day to the beginning of the next day. Unfortunately the same logic does not seem to apply to custom user defined time windows. For example if one wanted to do midday to midday i.e. 12:00 to 12:00 then Retrospect rejects this and will not accept it at all and therefore will not treat it as covering a 24 hour period. This is not only I feel a bug it is rather annoying since despite what Retrospect themselves may think I am not going to be coming in to the office to change over the backup media at midnight each day. As a result if typically one did change over the media at midday with the standard 00:00 to 00:00 window then actually you will only get backups happening for half the day at most.
  3. I've been wondering this for a long time now, but have never figured it out or gotten around to asking here. So, I have a site w/ numerous clients, all added to a Proactive script that has 3 sets for its destinations: Alpha, Bravo, and Charlie. When I look at Activities > Proactive > Destination column, I see 1 of these 3 sets next to each entry. However, I may have Set Bravo connected (like now), yet some of the clients show the Destination as Set Alpha. Why? So, even if the client is in need of backing up (every 24 hrs) and says Destination is Set Alpha, since I have Set Bravo connected, it won't back up. Some questions about this aspect of the Proactive scripts: 1. How is Retrospect determining the set it lists under Destination? 2. Is there any way to manually change the set (w/o some crazy cheat or workaround, I mean)? 3. Is there any way to "nudge" Retrospect to go ahead and back up a client when I know it is now connected, active, and has a suitable backup set available***? *** = I just watched it take 20+ minutes to start backing up a machine that hadn't backed up in weeks, despite clicking Schedule and setting it for the current time. In the meantime, another overdue spare MacBook that I woke up to also back up went back to sleep. Just seems like this should be quicker, or at least able to be hurried along while I'm in the Console. Thanks, Fred P.S. This is on v13 Multi Server, but also occurs on many other installations I support from v10.5 thru v13.
  4. I have a backup script that copies several volumes and folders to a dedicated external drive. I have two of these drives that I alternate between. I only need to complete this backup once a week to whichever drive is present. Previously, I used a two regular scripts for these backups. I wanted to combine them into a single script with both destination volumes set up in Media Sets. As a regular script, however, I found that Retrospect would get stuck looking for the missing media set. So, I changed to a proactive script, thinking that the script would run only on the available destination, regardless of which volume was present. Rather than use the default schedule of continuous operation, I've set my proactive script to run weekly on Sundays at midnight. For the past two Sundays, though, the script has not run and no backup has been attempted at all to the available drive. Was I mistaken? Is there a better setup here? Is the only approach to separate the scripts again? Is Proactive appropriate since one of the two drives is always absent? Or, should I return to standard scripts, separate media sets, and hope that each week one of the two will succeed because its media set is available and the other will fail because its set is not—but it won't get stuck.
  5. Hi, II've got three external drives for bacups which I rotate. Only one is connected at any time. Each drive has a unique backup set name (bu1, bu2, bu3). Similarly, I have three proactive jobs (job1, job2, job3). The jobs are identical except each has it's own unique destination (bu1..bu3 respectively). But since moving to a new PC jobs are starting to run even without the assosiated backup set connected. I then get a dialog asking me to locate the missing backup set. This never happened on the old PC. After all, isn't that the whole idea of proactive backups; that jobs don't start till all the necessary components are available? The Activity Monitor/Proactive/Backup Sets always shows one external drive as ready while the other two have status of "Media". What's going on. Can I fix this? Thanks, PP
  6. I have read many times about the algorithm used with proactive backups and how it puts the clients that have never been backed up at the top. Also it is supposed to optimize the proactive backup procedure. I have to assume this works well for other users but it does not work well for us. We have a lot of clients in our database and it takes a long time for the proactive backup to get through the entire list. I like that it seems to seen when a client connects and may start that backup right away, but I would really like the option to just let the process go through from never backed up to most recently backed up without trying over and over again to backup machines that are not in the office. This could be setup as an option, to use the algorithm or just go from top to bottom in the list. Also even when a client is set to be deferred it is not skipped over immediately. It seems to poll the client to see if it is there instead of just skipping it. This also seems to be the case when it gets to the bottom of the list. It runs through clients that were already backed up that day instead of skipping them. I would be very willing to talk with Retrospect designers about this. I like Retrospect and I think it is a good product, but I think it can become a great product. Thanks for all your work to make this product even better. Jeff
  7. Hello, We have a Retrospect 10 server with a proactive backup script, and this error appears in the script logs. "!Trouble reading files, error -519 ( network communication failed ) We have 10 Mac clients all setup to backup proatively. This error appears in the logs for various clients at one time or another. Questions: 1. What could possibly cause this error? 2. Where should I start troubleshooting? Any tips/tricks on isolating the cause, or minimizing it as much as possible so we can get more successful proactive backups. Our Configuration: -Apple MacMini, 2Ghz ZIntel Core 2 Duo, 2GB ram -OSX 10.6.8 -Retrospect server 10.1.0 (221) -Retrospect client 11.0.0 (191) Thanks for your time.
  8. I have Retrospect 10.5 running on Mac OS 10.9.3, backing up 52 mostly Mac clients with 10.x.y agents on a standard 100Mbs Ethernet HP procurve network. Firewall is off. Sources have been added by direct IP address. There are 9 proactive scripts designed to run all the time. But they do not run at all and no activity shows. Source statuses all says 'to be determined'. I have tried changing source, script and media set settings but the sources are polled and the status of each says 'not yet determined' I can easily make a normal backup script run and it will find and backup clients, but proactive remains static. JW
  9. Is there a way to Force PROACTIVE Script to Run ?
  10. Starting Proactive backup

    Proactive backup only runs in Normal mode. Does this mean a full/recycle backup also has to be run before starting proactive, to be able to do a complete current restore?
  11. I have a proactive that runs on the weekend, but wanted it to run *now* to test recent changes. I went to the "schedule" tab on the script, and added a second "schedule" by pushing the "+". I set it to be active on thursday (today), and planned to remove the second "schedule" when the backup ran. When I pressed "save", the "thursday" schedule **replaced** the weekend schedule, rather than being added to it. (two entries) I have yet to have two entries in the schedule that work. If there is a "+" button, it should work. If it doesn't work, it should be disabled.
×