This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Understanding Schedule Logic & Strategy

Hi All,

A two parter-

1) Is there a good KB on understanding the scheduling logic? I read the "understanding schedules" but it didn't help past the obvious.

For example if you add a new machine using the wizard and set it to backup once a day at 5:00 PM the core creates a schedule with a start time of 5:00 PM and end time of 6:00 PM and a duration of 1:00 hr. However if you manually set a schedule to do this it takes a backup at 5:00 and another at 6:00. If you set it so start at 5:00 and end at 5:01 with a duration of 1:00 hr you get one backup. I won't even tell you how long I fought with a noon and midnight backup. I never did get it to work and used 1 and 1 is how.

2) What is the general consensus on scheduling many machines to backup and not become a mess of machines in queue?

I just added one server at a time on a once a day schedule, took a base image and then accelerated all the schedules once the backup sizes were under control. I'm not sure what will happen when it decides to re-seed.

Thanks,

  • 1. I recommend this KB - support.quest.com/.../147461. It holds true for Rapid Recovery as well as AppAssure. It also describes your situation exactly. The backup window is the time period in which backups can be started. The interval is the number of times within that window that the backup will be called. The maximum concurrent transfers specifies how many concurrent backups can run. If you have more agents to backup than can actively run in the backup window, you will see some machines be skipped because their backup couldn't start within the window.

    2. What's the concern with having machines in queue? Why not let the software handle the queueing? If you want 2 backups a day set the backup window to be 24 hours (12 AM - 11:59 PM) an the interval to be 12 hours. The core will call the first backup for all machines with that schedule at 12 AM. By default only 3 concurrent backups happen. So it will run 3 backups starting at 12 AM. As a backup completes it will call the next one and so on until all backups that were supposed to run on that schedule are complete. Then it will repeat the process at 12 PM. The software is designed to take the backups as close to the schedule and interval you set as possible. Sure, you may not get exactly 12 hours in between each backup, but it will be pretty close.

    Obviously with base images which take significant time, there is no way that you are going to get the scheduling to work properly. Backups are going to end up queued for long periods of time as you wait for the base images to complete. It's only once incrementals are running for all machines that the queuing and backups will run efficiently and match your schedule since the backups should be taking minutes rather than hours.
  • Hi Tim,

    I still can't read the KB's as I'm having some license renewal issues and can't register. I have our renewed AA license files but RR seems to want something else. I have already contacted our rep and I'm sure he will straighten me out.

    No real concern with letting the queue stack up I just though I may be missing something. I am part of a large LAN/WAN that has other large backups running around the clock so we try to all get along and stay on our schedules.

    I will say I did try the 24hr 12-12 thing and was getting odd results with scheduled snapshots. Like skipping whole days. Maybe I just didn't let it run out long enough for it to auto correct but since I did it the way I described it's been dead on every checkpoint. And yes after the base image the incrementals have been short and sweet so it's working well even with exporting standby VM's.

    I will tag this solved.
  • Here is the info from that KB: 

    Backup window – The backup windows dictates the period of time in which a backup for that agent may be initiated. For example, if the backup window is set from 12 AM – 1 AM, then backups may be initiated for that agent starting at 12 AM but not after 1 AM. Hence there is a 1 hour period of the day where backups may run. 

    Snapshot interval – The snapshot interval dictates the interval at which snapshots will be taken within the backup window. For example, if the backup window is 1 hour long and the snapshot interval is set to 1 hour, then only 1 snapshot will be initiated during the backup window. If the backup window is 1 hour long and the interval is set to 15 minutes, then as many as 4 backups may be initiated during the backup window. 

    Click To See Full Image.

     
     
     
     

    Maximum Concurrent Transfers - The maximum concurrent transfers setting specifies how many backups may be running at the same time. By default the value is set to 3, which limits the number of simultaneous backups to 3. If the maximum number of backups allowed to run are already in process, the scheduler will wait until a backup slot becomes available before it will initiate the next backup. This means that it is possible for a backup not to be initiated because there is never an available slot during it's alloted backup window. 

     

    This process may cause issues for customers who are running only 1 backup per day and have a large number of agents. For example, if the backup window for 20 agents is set to 1 hour (12 AM - 1 AM) and the interval is set to 1 hour that means that only 1 snapshot will be taken for each agent that day.  However if the maximum concurrent transfers is set to 3 that means that only 3 backups will run at the same time. If the backups of the agents takes longer than 1 hour, there is a high likelihood that a number of agents will not backup because there is never a free backup slot during the backup window. 
     
    To avoid this issue, ensure that the backup window is set long enough that all backups can complete within that time frame and that the interval is still the same length or longer than the backup window (otherwise more than one backup will be taken).