The SQLite-based persistent storage back-end is implemented in μD3TN as an ordinary CLA. Bundles sent via this CLA are written to a SQLite database instead of being transferred to another node. By default, a volatile in-memory database with shared cache is used (`sqlite:file::memory:?cache=shared`). As several database connections are open, the `cache=shared` option is mandatory. To save bundles beyond the lifetime of the μD3TN, a dedicated database file must be specified (e.g. `sqlite:~/ud3tn.dtn`). Bundles can also be fed back into the μD3TN. From the point of view of the μD3TN, returning bundles is no different from receiving bundles via a CLA.
To interact with the SQLite storage, for example to delete bundles or send them to μD3TN, special commands can be sent to a local application agent that is connected to the SQLiteCLA. The [protocol spoken by SQLiteAgent is based on Protobuf](../references/protobuf/#componentsagentsstoragestorage_agentproto) and allows to apply an operation to a set of packages selected by the destination EID.
### Option 1: Using the external next-hop routing BDM
This is the easiest option to use the persistent storage. Just launch µD3TN with the external BDM and it will make use of the storage system automatically.
1. Run μD3TN with enabled MTCP and SQLite CLA and external dispatch flag
If the BDM restarts while bundles are in persistent storage, the bundles have to be recalled manually to re-schedule them, _after applying all necessary configuration_ (e.g. scheduling contacts):
In real scenarios, the storage is accessed via a BDM. The BDM decides when bundles should be sent to the storage and when they should be retrieved. Nevertheless, for simple tests, you want to interact with the storage without a BDM. This requires a workaround in which a "virtual" contact to the storage is configured.