Scheduler priority and start

[mlowery]

Hi,

I have two related questions. I have a scheduled time for backups, but occasionally the system is hibernated or shut down at the scheduled time. I would like:

A) To start the missed backup at a reasonable time after the system is next started or woken from hibernation. The "run missed daily jobs immediately" option starts them as soon as someone logs on or restarts the system, regardless of any other boot processes, and can significantly delay the usability of the system when booted. Is it possible to set the "retry" time for missed jobs to some time after the boot has completed, or to wait until the system CPU load is below a certain value?

B) Is it possible to set the process priority for the backup process lower, to "Idle," so that even when the backup process kicks off, it yields to any active programs? One alternative to the above issue is to set the scheduled backup time to be during known working hours. Manually forcing it to "Idle" priority using the Task Manager/Process Monitor tool lets me continue working without significant system impact; the default priority brings the system to a crawl during backup. I'm currently using the "background scheduler." If there are more options with "service scheduler," that's also acceptable.

Thanks for such a truly flexible backup system!

[Scott]

I also have serious issues with SFFS slowing my system. I constantly have to adjust its priority while backups are running, because I want it to run as quickly as possible when I'm away, but I can't have it grinding my system to a halt when I'm using the system.

Unless/until some native solution is implemented, the best way I've found to deal with the problem is to use Process Lasso and the Process.exe command line utility. The former can be used to set a default priority to the process, to dynamically (and temporarily) reduce its priority, and to manually alter the priority, while the latter can be used to manually adjust the priority using shortcuts.

[superflexible]

Hello,

you can specify an idle time after reboot for the scheduler on the Program Settings dialog, tab sheet "Startup".

The jobs typically don't use much CPU because they are always waiting for hard disk or Internet transfers. A general system slowdown is extremely rare and might be related to the types and number of jobs that you are running. However, if you need to reduce CPU usage, you can also set the program to use only one CPU core. This is done with the checkmarks on the tab sheet Miscellaneous.

[mlowery]

Thank you for the suggestions.

The "startup delay" option is checked. I believe the issue is that that delay is only considered when the computer is fully restarted (cold or warm boot) and the scheduler is initially started. When I hibernate the system and boot to un-hibernate after the scheduled backup time, the scheduled profile(s) either start immediately (if the "run missed jobs immediately" option is checked in the profile), or skips that day's backup, since the scheduler is just restored from the hibernation state, not restarted as it would be after a full system restart.

Perhaps a different combination of scheduler settings (background/foreground/service) and auto-start (when needed/when windows on/never) would help?

For slowdown, the high CPU use I'm experiencing is during the scanning/database comparison phase. The program is limited to one CPU and a single simultaneous profile. Lowering its priority solves the issue, but does require a workaround. Since you have redesigned the database for version 5, I would be willing to migrate to that version to see if it helps, as long as migrating won't affect my license.

[superflexible]

Hello,

yes it is true that the program doesn't recognize if the computer has woken up from sleep or hibernation. The only thing you could do is schedule your jobs less frequently or use "Real Time" scheduling. Both of which would reduce the load on your computer. Real Time is not appropriate in all cases, however, so you'd need to try to see if it works for you.

Yes the database engine in version 5 should be much more efficient. Version 5 will take the same registration codes as version 4, so it is a free upgrade for all version 4 customers.

[mlowery]

I've migrated to version 5, and as a test to see if I can improve performance, have edited my main backup profile as follows:

• Changed the daily schedule to weekly
• Turned on real-time sync with an interval of 2 hours

Doing so results in an "Access Violation" error in the ExtremeSyncService.exe (displayed in red in the main SFFS window in the job status column). In the Real-time settings, only the "rename" and "ignore temporary" settings are checked (since the profile has already run completely, and I don't care about syncing deletions continuously). The drive being monitored is the C: drive, so there are probably many changes to track, though the profile rules exclude unimportant system files and so on.

Is there information I can provide to help troubleshoot the issue, or am I doing something wrong?

[superflexible]

It's probably also mentioned in the log files with more details, you could send one to info@superflexible.com. There will be another update today.

[superflexible]

Hello,

the new preview build 37 is now on our web site and it should fix the real-time access problems.

[mlowery]

I just tried build 37 and am getting the same error. The log isn't providing any additional information. With all extra log troubleshooting options on, the log ends after "The profile is executed by the background scheduler."

I have a different real-time backup that works fine, so I suspect that the issue is something to do with adding realtime to a profile that already has a schedule and database, but I really don't know. I can capture the "access violation" error text with memory address if that's helpful.

[superflexible]

Yes I need the memory address.