Timer jobs is a great feature of SharePoint to use when you need to perform background execution at regular or specific times or when you need to execute code on all or selected servers in the farm. A timer job is a persistable object deriving from the SPJobDefinition class.
SharePoint 2010 has updated this class in many ways, to the better. Not only can the timer jobs be configured and monitored better through Central Administration they can also be invoked on demand.
SPJobDefinition changes
The SPJobDefinition class in SharePoint 2010 has received some major updates. First of all the class now inherits from IBackupRestore which is an interface that tells that the timer job can be backed up. The IBackupRestore interface contains methods that you can override and implement to perform actions before and after restores and backups of the timer job. You need to override the EnableBackup property and return true if you would like to make a backup of the job.
Another great addition is that all timer jobs now have a Progress value (ranging from 0 to 100) which you can set by calling the UpdateProgress(int) method. Awesome for long running timer jobs and the progress is shown in Central Administration.
The new timer job method RunNow() creates a one-time-schedule and schedules it immediatley, if it is not disabled.
There are lot of new timer job classes that all inherits from the SPJobDefinition. They are specifically made to target different types of artifacts of SharePoint. Some of the most interesting and valuable are:
Pausable Timer Jobs
You can now create pausable timer jobs. This is done by inheriting from the SPPausableJobDefinition and overriding Execute(SPJobState) instead of Execute(Guid). You can then use the current job state (SPJobState) to store values which are retrieved when the job is resumed.
Running jobs on all content databases
Another new timer job derivative type is the SPContentDatabaseJobDefinition.This is a timer job specifically made to perform actions on content databases. The timer job is distributed on the WFE servers and each content database is only processed by one job. Override the Execute(SPContentDatabase, SPJobState) to add your own processing. The job supports pausing.
Running jobs on all Site Collections
A really interesting new timer job type is the SPAllSitesJobDefinition. This one is derived from the SPContentDatabaseJobDefinition and has a method called ProcessSite(SPSite, SPJobState) which you override to process the SPSite object. This could be very useful to build site inventories/directories.
Running job on a specific server
The SPServerJobDefinition is a pausable timer job that is designed to be targeted to a specific server (SPServer).
Running jobs for specific services
The SPServiceJobDefinition is another pausable timer job that runs a job on all servers where a specific SPService has been provisioned. A very similar job is the SPFirstAvailableServiceJobDefinition which runs the job on the first available server which has a specific SPService installed. If you would like to run a job an all servers you can easily use SPServiceJobDefinition. Then use the timer job service (which is installed on all servers, except dedicated database servers) and pass SPFarm.Local.TimerService as the SPService parameter in the constructor.
All of the new specific timer jobs are essentially smart derivatives of the SPJobDefinition but using these new abstract classes will certainly save you some time when you need to target your timer jobs.