When you schedule backups using SQL Server Agent and am in a region that uses daylight saving time, you need to take into consideration a couple of issues that may affect your disaster recovery plan.  Note that these issues are not specific to SQL Backup, but affect every SQL Server Agent scheduled job.

Let's say we've scheduled a transaction log backup to run every 5 minutes.  Consider a daylight saving fall-back scenario from 2 AM to 1 AM:

• at 1:55 AM (pre fall-back), the backup job runs and completes
• the next backup job is scheduled for 2 AM by SQL Server Agent
• at 1:59.999 AM, the fall-back occurs, and the clock resets to 1 AM (basically 1 AM occurs twice, but 2 AM occurs only once)
• from the post fall-back time of 1 AM to 1:59 AM, no backups will run
• the next backup runs at 2 AM post fall-back time

Note that there is a 1 hour gap where the transaction log backup is not ran.  If it is critical that you have consistent 5-minute backups, you will need to run additional backups yourself, or modify the existing job during the changeover time.

Now consider the spring-forward scenario, from 2 AM to 3 AM.

• at 1:55 AM (pre spring-forward), the backup job runs and completes
• the next backup job is scheduled for 2 AM by SQL Server Agent
• at 1:59.999 AM, the spring-forward occurs, and the clock resets to 3 AM
• when SQL Server Agent detects the time change, it will find that the job at 2 AM is past due, and runs it immediately

Now, no backups are omitted, but if you had other jobs originally scheduled at 3 AM 'normally', they will compete for resources or collide with jobs that were scheduled between 2 AM and 3 AM, as those will run immediately post-changeover.

File naming conflicts

The default naming convention for SQL Backup backup files uses values from the current date and time e.g. LOG_PROD_AdventureWorks_20210218_081000.  When you create additional backups during the changeover hour in the fall-back scenario described above, you need to ensure that the naming convention for the additional backups do not conflict with the backups already created by the scheduled job.

Be careful that you do not use the INIT option in your backup commands, as this will cause SQL Backup to overwrite any existing backup files of the same name.  This is especially important for transaction log backups, as overwriting any of the existing backup files will break the entire log backup chain beginning with the file that was overwritten.