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,

Parents
  • 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.
Reply
  • 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.
Children
No Data