I recommend deleting the Links first, then Item, then Things. I’ve seen cases where the Link remains and that leaves the Item in a kind of zombie state. I’ve only found that it can be removed by manually editing the JSONDB file.
All of your Things and Items and Links created through the REST API or PaperUI get stored in the JSONDB (e.g. /var/lib/openhab2/jsondb). On every change and periodically, those files are automatically backed up by openHAB (e.g. placed in /var/lib/openhab2/jsondb/backups).
When running openhab-cli, both /etc/openhab2 and the contents of various files in /var/lib/openhab2 to include the config and jsondb folders are included in the backups. These can be restored using openhab-cli restore.
When you use openhab-cli (or manually backup the userdata folder (i.e. /var/lib/openhab2) minus the tmp and cache subfolders) the restore is exactly what you would expect. All bindings get installed. All configurations, whether made in the conf folder or through the karaf console or the REST API get restored. All Things and Items and Rules and whatever, whether it was defined in conf or through the karaf console or the REST API get restored as well.
I believe (but would need to verify) that openhab-cli also backs up important files from individual bindings (e.g. zwave and MQTT 2.x both have folders in userdata) and embedded persistence files (e.g. mapdb and rrd4j files).
If you use openhab-cli backup/restore you can backup and restore your entire OH, not just it’s Rules, Things and Items, in a matter of minutes. When you use the REST API or karaf to create Items, Links and Things, those changes get backed up as you make them
That’s interesting as for the majority of people who post problems it’s the opposite. They have problems with the .things files which are solved when moving to configure through the REST API (e.g. PaperUI).