A full backup can be obtained by paging through the whole output of the system history interaction. Such paging should be stable on a FHIR server. So no versions should be missing or duplicate.
Incremental Backups
After the first download of all versions, incremental backups are possible using the _since query parameter. The last seen versions timestamp can be obtained through response.lastModified.
Full Restore without History
The history bundles can be processed from the most recent to the least recent. For each entry:
the combination of resourceType and id will be looked up in a table
if the resource was already processed or the request is a DELETE, the entry will be skipped
if the request is a POST or PUT, the entry will be appended to a transaction bundle
Transaction bundles are then POST'ed to the server to restore. The result would be that all resources are restored but without any history.
The idea doesn't work, because referential integrity will most likely violated on restore. But I'll leave this here for possible improvements.
The idea is to implement a simple backup using the system history interaction.
Full Backup
A full backup can be obtained by paging through the whole output of the system history interaction. Such paging should be stable on a FHIR server. So no versions should be missing or duplicate.
Incremental Backups
After the first download of all versions, incremental backups are possible using the
_sincequery parameter. The last seen versions timestamp can be obtained throughresponse.lastModified.Full Restore without History
The history bundles can be processed from the most recent to the least recent. For each entry:
Transaction bundles are then POST'ed to the server to restore. The result would be that all resources are restored but without any history.