Jump to content

earthsaver

Members
  • Content count

    10
  • Joined

  • Last visited

Community Reputation

3 Neutral

About earthsaver

  • Rank
    Member
  1. While I find the logic unintuitive, the 20-hour lapse seems to be working and I guess I could set it to any timeframe shorter than seven days for a backup that I want to run once a week. Thanks all for your guidance!
  2. You are correct that Retrospect attempted 24 backups of each source when set to "every 1 hour." However, while it respected the day set in the schedule (Saturday), it did not respect the time window: 8 pm to 5 am. Instead, the backups ran from 12 am Saturday to 12 am Sunday. I'll now try the suggested 20-hour minimum lapse and a Tuesday-only schedule (so I can see if anything happened when I'm back in the office on Thursday. If it works, I'll set it to Saturday only and hope the issue is resolved.
  3. Can you specify what details you're expecting? I don't know what other schedule view there is to show you.
  4. Here are my latest settings: As soon as I saved the script with the these changes, the backup in question started running. Unfortunately, since the media set is the same for all five sources, and Retrospect treats them as five separate backups, it doesn't seem to know how to run them in sequence. It initiates one and the others report that the media set is in use, and then that they will wait until the next backup. Perhaps the only way to accomplish this is to set the script for every hour from 8 pm to 5 am and hope that Retrospect runs the sources in sequence rather than starting from the beginning.
  5. To be sure, I rebuilt the script from scratch on Monday morning. Sorry I forgot to mention that. Let me see if I'm understanding how this script scheduling works. Every X hours/days, Retrospect will check to see if the current time is between From and To. If it is (and if Allow Early Backup is unchecked, only if it is), Retrospect will initiate backup of the sources. If it is not, Retrospect will wait another X hours/days and check again. Until this morning, the script was set to backup sources every day on all days between 12 and 6 am. It has still not run automatically since Monday. Does anyone know the philosophy behind this first setting? My intuition suggests that Retrospect should just initiate the backup when the From time occurs. There could be a setting to either continue until the backup finishes or stop when the To time occurs. If this is not how it works and others agree, I'll send feedback to the company. I've now set the script to backup every hour every day at all times. We'll see if it runs at all in the next couple hours.
  6. The only difference I can see is the restricted schedule. If I change the script to all day every day and allow it to run early (a time that doesn't even exist in this range), then it immediately starts running. Have I found a bug that I now need to report to Retrospect? I wonder if it's already been resolved in version 12. My company is not likely to upgrade to 12, though.
  7. Even after changing the schedule to include all day today, nothing happened. Only after I changed the script setting to "Allow early backup" did the script immediately start running. It's as if Retrospect is unable to follow a restricted schedule for a proactive backup. I also posted about this on another thread regarding the "script not active" status in the script's Activity Summary. I don't understand why activities associated with this script are inactive, except for the fact that they're not currently running. Other proactive scripts are active when their media sets are available, or are identifying that the media set is in use or the source is not available.
  8. I'm experiencing a similar issue. The "Script not active" status appears in the Activity Summary, where active scripts have a green border around the icon and inactive scripts do not. One of my destinations for the Catastrophic Pro script is connected all the time; the other is in a secure location. They get swapped once a month or so. Is the fact that the drive is always connected problematic for proactive scripts? This script is set to run daily between midnight and 6 am, and is not permitted to run early (whatever that means). Before today, I had set it to run only once a week and it was failing to do so.
  9. Thanks for your thoughts, Lennart! I'm glad to hear I'm on the right track. I have scheduled the proactive script for Sundays from 12 am to 6 am. This script normally takes an hour or less to complete because all of the sources are on local volumes. Notably, I'm using Retrospect 11 and do not have the ability to schedule the script to end on a different day than it begins. Also, I had the script set to run every 7 days and I've just changed it to every 1 day in case that might resolve the issue. I'll let you know if anything changes.
  10. 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.
×