The feature is defined in RFC-4741 as:

If the device reboots for any reason before the confirm timeout
expires, the server MUST restore the configuration to its state
before the confirmed commit was issued.

The Confirmed Commit Cabability v1.1
defined in RFC-6241
does not change this definition.

Implementation would require to save DS state on disk.

The state should be saved when confirmed commit is received,
but before it was applied.

Whether to save state on follow-up commit is not clear from the RFC.

It says only about timer reset and possible additional changes to config,

but does not say which configuration should be used for config restore.

The patch to the file where the saved state is stored needs to be configurable.

There is no need to store timeout timestamp, because restore is unconditional

(e.g. should happen even if commit confirmation arrives after restart but before timeout).

The saved state should be removed when commit is confirmed or when timeout occurs.

Netconf server on start should restore the persisted state and create appropriate timer.

 
Support for persisted commit (v1.1) implies that user might be able to restore rollback any of them using

<cancel-commit> operation.

But which one snapshot to use when device reboots?

This is not clearly defined in the RFC and should be further investigated.