Now you understand your organization’s data protection needs and you have the means to implement them. To bring it to life, you need to design the schedules for your backups. Unless you have very little data or a high budget for backup, you will use more than one schedule. You will use three metrics:
  1. Value
  2. Frequency of change
  3. Application features

Understanding How the Value of Data Affects Backup Scheduling

The frequency of your full backup schedule directly determines how many copies of data that you will have over time. The more copies you have of any given bits, the greater the odds that at least one copy will survive catastrophe. So, if you have data that you cannot lose under any circumstances, then your schedule should reflect that.

Understanding How the Frequency of Change Affects Backup Scheduling

Data that changes frequently may need an equally frequent backup. As you recall from part one, recovery point objectives (RPO) set the maximum amount of time between backups, which establishes the boundaries of how much recent data you can lose. You must also consider how often that data changes independently of RTO.

If you have data that does not change often, then you might consider a longer RPO. If you only modify an item every few months, then it might not make sense to back it up every week. However, that might have unintended consequences.

As an example, you set a monthly-only schedule for your domain controller because you rarely have staff turnover and only replace a few computers per year. Then, you hire a new employee and supply them with a PC the day after a backup.

If anything happens to Active Directory during that month, then you will lose all that new information. Your schedule needs to consider such possibilities.

Understanding How Backup Application Features Affect Scheduling

You will find that modern commercial backup applications have more in common than different. They all have some way to schedule jobs. Each one uses some way to optimize backups. The exact features in the solutions that you use will influence how you schedule.

The following list provides a starting point for you to determine how to leverage the features in your selected program:

Virtual machine awareness

If your backup software understands how to back up virtual machines, then you can allow it to handle efficient ordering. If not, then you will need to schedule to back up the guest operating systems such that the jobs do not overwhelm your resources.

Space-saving features

If your backup tool can preserve storage space, that has obvious benefits. Everything involves trade-offs – ensure that you know what you give up for that extra space.

Some common considerations:

  • Traditional differential and incremental backups complete more quickly than the full backups they depend on. They mean nothing without their source full backup. Design your schedule to accommodate full backups as time and space allow;
  • Newer delta and deduplication techniques save even more space than differential and incremental jobs but require calculation and tracking in addition to the requisite full backups. They should not use significant CPU time, but you need to test it. Also check to see if and how your application tracks changes. Some will use space on your active disks;
  • If you have extra space in your storage media, then do not depend overly on these technologies. Create more full backups if you can.

Time-saving features

Many of the features in the previous bullet point save time as well as space. As with space, do not try to save time that you do not require.


Replication functions require bandwidth, which can cause severe bottlenecks when crossing Internet links. If a replication job is not completed before the next job begins, then you might end up with unusable backups.

Media types

Due to the wide variance in performance of the various backup media types, the option(s) that you choose will determine how you schedule backups and what space-saving features they use. For instance, if you need to back up several terabytes to tape and a full backup requires twelve hours to perform, then you can only run a full backup when you have twelve hours available.

Snapshot features

If your backup application integrates with VSS (Volume Shadow copy Services – a feature of the Windows Operating System) or uses some other technique to take crash-consistent or application-consistent backups, then you have greater scheduling options.

Backup uses system resources and you do not want one job to conflict with another, but snapshotting allows you to run backups while systems are in use.

You should have become well-acquainted with your backup program during the deployment phase. Take the time to fully learn how your backup program operates. Keep in mind the need for periodic full backups.

Putting It in Action

Since taking full backups every time would quickly exceed any rational quantity of time and media, you must make compromises. Remember that, if possible, you would take a complete backup of all your data at least once per day.

Guidelines for backup scheduling:

  • Full backups need time and resources, even with non-interrupting snapshot technologies. Try to schedule them during low activity periods.
  • Full backups do not depend on other backups. Therefore, they have greatest value after major changes. As an example, some organizations have intricate month-end procedures. Taking a backup immediately afterward could save a lot of time in the event of a restore.
  • Incremental, differential, delta, and deduplicated backups require relatively little time and space compared to full backups, but they depend on other backups. Use them as fillers between full backups.
  • If your backup scheme primarily uses online storage, make certain to schedule backups to offline media. If that is a manual process, implement an accountability plan.
  • Just as administrators tend to perform backups at night, they also like to schedule system and software updates at night. Ensure that schedules do not collide.

Grandfather-father-son sample plan

“Grandfather-father-son” (GFS) schemes are very common. They work best with rotating media such as tapes. One typical example schedule:

  • “Grandfather”: full backup taken once monthly. Grandfather media is rotated annually (overwrite the January 2020 tape with January 2021 backup, February 2020 with February 2021 data, etc.). One “grandfather” type per year, typically the one that follows your organization’s fiscal year end, is never overwritten, following data retention policy.
  • “Father”: full backup taken weekly. “Father” media is rotated monthly (i.e., you have a “Week 1” tape, a “Week 2” tape, etc.).
  • “Son”: incremental or differential backups are taken daily, and their media overwritten weekly (i.e., you have a “Monday” tape, a “Tuesday” tape, etc.).

The above example is not the only type of GFS scheme. The relationship of the different rotation components is how it qualifies. You have one set of very long-term full media, one shorter-lived set of full media, and rapidly rotated media.

Some implementations do not keep the annual media. Others do not rotate the monthly full, instead keeping them for the full backup retention period. Some do not rotate the daily media every week. Your organization’s needs and budget dictate your practices.

With a GFS scheme, you are never more than a few pieces of media away from a complete restore. Remember that a “differential” style backup needs the latest “son” media and the “father” immediately preceding whereas an “incremental” style backup needs the latest “father” media and all of its “sons”.

The downside of a GFS scheme is that you quickly lose the granular level of daily backups. Once you rotate the daily, then anything overwritten will, at best, survive on the most recent monthly or perhaps an annual backup. The greatest risk is to data that is created and destroyed between full backup cycles.

Online media sample plan

If your backup solution uses primarily online media, then the venerated GFS approach might not work well. Most always-online systems do not have the same concept of “rotation”. Instead, they age out old data once it reaches a configured retention policy expiration period.

For these, your configuration will depend on how your backup program stores data. If it uses a deduplication scheme and only keeps a single full backup, then you have little to do except configure backup frequency and retention policy.

Continuous backup sample plan

Many applications have some form of “continuous” backup. They capture data in extremely small time increments. As an example, Hornetsecurity’s VM Backup has a “Continuous Data Protection” (CDP) feature that allows you to set a schedule as short as five minutes.

Scheduling these types of backups involves three considerations:

  1. How does the backup application store the “continuous” backup data?
  2. How quickly does the protected data change?
  3. How much does the protected data change within the target time frame?

If your backup program takes full, independent copies at each interval, then you could run out of media space very quickly. If it uses a deduplication-type storage mechanism, then it should use considerably less. Either way, your rate of data churn will determine how much space you need.

For systems with a very high rate of change, your backup system might not have sufficient time to make one backup before the next starts. That can lead to serious problems, not least of which is that it cannot provide the continuous backup that you want.

You can easily predict how some systems will behave; others need more effort. You may need to spend some time adjusting a setting, watching how it performs, and adjusting again.

Mixed backup plan example

You do not need to come up with a one-size-fits-all schedule. You can set different schedules. Use your RTOs, RPOs, retention policies, and capacity limits as guidance.
One possibility:

  • Domain controllers: standard GFS with one-year retention
  • Primary line-of-business application server (app only): monthly full, scheduled after operating system and software updates, with three-month retention
  • Primary line-of-business database server: continuous, six-month retention
  • Primary file server: standard GFS with five-year retention
  • E-mail server: uses a different backup program that specializes in Exchange, daily full, hourly differential, with five-year retention
  • All: replicated to remote site every day at midnight
  • All: monthly full offline, following retention policies

To properly protect your virtualization environment and all the data, use Hornetsecurity VM Backup to securely back up and replicate your virtual machine.

We ensure the security of your Microsoft 365 environment through our comprehensive 365 Total Protection Enterprise Backup and 365 Total Backup solutions.

For complete guidance, get our comprehensive Backup Bible, which serves as your indispensable resource containing invaluable information on backup and disaster recovery.

To keep up to date with the latest articles and practices, pay a visit to our Hornetsecurity blog now.

Sum Up

Remember to document everything!


What is a backing schedule?

A backup schedule defines the frequency of data backups and the required backup media. Each hardware type offers various rotation schemes, including industry-standard strategies, and these schemes can be customized after creating the backup job.

What is a good schedule to run a backup?

Typically, performing incremental backups for user files during the daytime is recommended. However, it’s advisable to set maximum speed limits for backups to avoid bandwidth saturation. Full backups are best scheduled nightly and weekly on weekdays.

What is the importance of backup schedule?

The importance of a backup schedule lies in its ability to mitigate data loss in the event of a computer or system failure. By scheduling nightly or weekly backups, you can minimize the potential loss of data. Having a scheduled backup provides peace of mind, ensuring that all your information is regularly backed up, thereby reducing the risk of substantial data loss.