Nexus provides a rich and extensible set of tasks that can be scheduled. Internally, all long-running, or asynchronous task are modeled as scheduled tasks, which provides a consistent development model and exposes all the functionality for the user to schedule if they choose. What this means is that some tasks are not applicable to all users. I'll go through them all below.
Many of the tasks below apply to the same scenario so I'll cover it here.
If you are deploying or otherwise regularly changing the contents of the filesystem by some mechanism outside of Nexus, then certain internal states of Nexus may get out of sync (cache, index, etc) with the true contents of the disk. A common example is an organization migrating from using no repository manager, continuing to use webdav or scp to deploy while they migrate.
Repositories have several caches to improve performance - this task expires the caches causing Nexus to recheck the remote repository (proxy) or file system (hosted).
Typically this is fired off from the right-click menu of a repository in response to temporary config changes, etc. This could be scheduled in the External Changes scenario covered above. A better approach would be to adjust the cache timeouts to a smaller number.
Maven best practices suggest you deploy snapshots on a frequent basis, usually from a CI system. If the snapshots aren't cleaned up, this can lead to lots of disk usage. The snapshot remover can clean out old snapshots based on their age keeping minimum number, or removing all copies when a release of the same version is detected. In all cases, maven-metadata.xml is properly updated.
This task should be scheduled to run daily at a convenient time. I generally keep 3 copies of snapshots (in the off chance I want to go back one or two to test some changes) with a minimum age of 1-2 days. I also like to have the Remove if Released option set. This causes our builds to fail in CI if we forget to upgrade to a released dependency.
This task purges items from proxy repositories that haven't been requested by a user in a set period of time.
This task is handy to recover disk space for versions of artifacts that are no longer used regularly. If they are needed again, they will be re-requested from the proxy. If you trust the availability of the remote proxy, then set this for some period like 90 days. If however you want to be sure Nexus has a copy of every artifact you've ever needed, then don't run this task. I generally set this for 90 days and let it run on the weekends. This is particularly handy if you have a personal Nexus instance where you might have a large churn in the artifacts you use and are more sensitive to disk usage.
All delete operations in Nexus don't actually delete files, they are simply moved to /sonatype-work/nexus/trash. This applies to scheduled tasks and manual deletions. This is done to give you a recovery path if you accidentally delete something incorrectly. Restoring files is currently a manual process of moving the files back, but trust me if you need it, you will hardly mind. (I speak from experience)
It's not required as you can manually purge the trash from the repository view when you need to recover disk space. Keep in mind that purged snapshots will end up in the trash so depending on your development cycle, it could grow quickly. I like to set this to run weekly on Sunday night...the logic being that I want the maximum time to discover and restore any artifacts before they get purged.
This task is similar to expire caches since it normally is invoked from the repository view to repair one-time changes. This task will rebuild the maven-metadata.xml files with the correct information and will also validate the checksums (.mh5/.sha1) for all files.
This would only need to be scheduled if you make External Changes on a regular basis as described in the first section.
This will check for new versions of indexes that may be published on remote repositories. Not all repositories publish indexes, but if they do, you can enable the download in the repository configuration for your proxy repository.
If you want to keep the indexes for searching and browsing remote repositories, then set this schedule. It's best to know how often the remote is updated and set your schedule accordingly. The Maven Central repository index is currently updated weekly on Saturday mornings.
This task bundles up the internal Nexus indexes that are maintained in realtime along with downloaded remote indexes and exposes them for download by other systems like downstream Nexus or M2eclipse clients. Publishing has no effect on the searching inside of Nexus, these indexes are always maintained in realtime. Producing the format for efficient download is nontrivial and the results are zipped so it's not practical to do this in real time, hence the ability to schedule it.
If you have downstream Nexus instances or users with M2eclipse, then you will want to schedule the publishing. How often and when depends on your needs. M2eclipse currently only looks for new indexes on startup so publishing every 5 minutes is likely overkill.
This task walks over the entire repository and rebuilds the internal indexes from scratch. It also checks for remote indexes and will publish the results when done. (i.e. it supercedes the Download Index and Publish Index tasks.)
You should rarely, if ever, have to reindex a repository, because Nexus maintains the internal indexes in realtime. If you are making External Changes as described above, then you would want to schedule a re-indexing, otherwise you're better off using the Download Index and Publish Index tasks.
The timeline is the internal audit of operations. This is currently only used to produce the RSS feeds.
The timeline can be purged to conserve disk space. In future versions, the timeline will form an audit path and this task will probably be disabled. For now only use it if you find the timelines are taking up lots of disk, otherwise it should be safe to ignore.
Shadow repositories are another name for virtual repositories. Virtual repositories allow you to convert data from one content type to another, for example Maven1 to Maven2, or Maven2 to OBR.
Shadow repositories manage themselves by laying down "symlinks" that point to the source repository. They are managed on the fly, but if you are making External Changes, then this is used to update the shadow repository to reflect actual change.
Shadow will still work and will deliver the newly copied files to maven (more precisely, will fulfill maven download requests) if they are present, but this task merely creates the folder structure and the symlinks and makes the /content tree browsable by syncing the master repo content with symlinks in shadow repository.
This is only needed if you have virtual repositories and you make External Changes to the source repository.
This Nexus Professional plugin creates archives of the Nexus configuration data.
We recommend running this at least daily to keep backups of the config.
This Nexus Professional P2 plugin allows you to mirror Eclipse Update Sites. Using this task, your Nexus will mirror the data from the remote repository.
The P2 plugin should handle this operation when necessary, however, should you get in a state where the mirrored content/metadata gets out of sync with the remote repository, you can run this task to get back in sync.