In December 2012 Microsoft published a whitepaper entitled SSIS Operational and Tuning Guide which you can download by clicking here.
I have skimmed through the whitepaper and it appears to be a compelling read however a couple of sentences caught my eye that I want to draw attention to here. These sentences refer to the use SSIS checkpoint files:
Some of the most common challenges with SSIS packages are in how to handle unexpected failures during execution, and how to minimize the amount of time required to finish the execution of an ETL process when you must resume processing after a failure. For control flow tasks such as file system tasks, checkpoints can be used to resume execution without reprocessing work that has already been completed.
When designing packages, one of the largest concerns is designing so that in the event of failure, you do not lose all of the progress the package has made up to this point. For items in the control flow of a package, this is accomplished by the use of checkpoints.
In blog post Why I don't use SSIS checkpoint files from March 2011 I explain my experiences of SSIS checkpoint files and why I choose not to use them. In addition there are a number of Connect submissions that speak to the problems associated with SSIS checkpoints:
Microsoft have not (as far as I know) publicly acknowledged any issue with SSIS checkpoints however I am certain that internally the SSIS product team know the current implementation is inadequate for many scenarios. With this in mind I am disappointed that a Microsoft whitepaper openly advocates the use of them without at least acknowledging their deficiencies.
Designing for restartability is hard. I personally choose not to use checkpoints and instead implement my own custom restartability solution; I am not saying steer clear at all costs but I hope that if you choose to use them that you both understand the implications of doing so and test that they behave as you expect.
@Jamiet