You schedule a backup to occur at day / time and choose your timing incorrectly (5:30am rather than 5:30pm).
Now to 'change' your schedule to pm rather than a.m. you are 'forced' into re-running your full if you use the provided Kaseya button 'Schedule Full'. Yuck. Now you have to 'burn' a full backup in order to fix a timing problem. This can cause not just headaches, but replication issues if you have to re-transfer a now unwanted full backup.
Disclaimer: !!! What you see in this SQL script is not for the faint of heart. Do NOT use this if you are not comfortable with doing things directly in SQL Management studio. You are making changes directly to tables and technically you can screw things up royally if you do things improperly. THUS, YOU ARE WARNED. Don't just go do this without first thinking about what you are doing and having a good SQL backup. Backups are your friend. Your mileage may vary.
I wrote a SQL script that will make the changes for you. I use this exact script frequently to fix these kinds of issues. Sometimes we think the schedule looks right at first and we just need to move things around by an hour or so to split up long backups over time.
This is how it used to be. Schedule for previous time and it would schedule the incremental in the future. Changed at some point for some reason. Really wish it was reverted back.
That's a neat way of doing it, but I have a simpler solution
Lets say you have full backups scheduled every 7 days on Fridays. Today is Wednesday and you need to fix the schedule. Change the scheduler at the top of the page to reflect 5:30pm last Friday with the skip offline option checked and hit schedule. After a few minutes reload the page and kaseya will show your desired next backup to be an incremental, tonight at 5:30pm, and your schedule will be in tact.
This also works when scheduling multiple backups. Lets say I have 30 agents, and I want full backups every 14 days and distributed times overnight starting at 6pm. I would select all agents, change the date to 30+ days in the past, set the stagger to something like 1470 (one day is exactly 1440, so 1470 would stagger the backups by 1 day and 30 minutes), make sure skip offline is checked, and schedule full. Then all the full backups will distribute themselves over that time in the past, but not actually run on the spot, and your future schedule will be set correctly with incrementals and fulls on the correct days.
1470 is also a kind of big window for a large number of agents, here are a few other numbers to keep in mind:
1440 = Exactly 24 hours
1450 = 1 day and 10 minutes
1455 = 1 day and 15 minutes
1470 = 1 day and 30 minutes
1485 = 1 day and 45 minutes
1500 = 1 day and 1 hour
And so on.
Scheduling back in time has been VERY handy for me, especially when onboarding new clients or adding one machine to a client that already has a backup schedule for the rest of their machines (I can easily reschedule them all to include the new machine in the rotation).
Hope this helps.