Retention and backups
Recordings
Section titled “Recordings”Antinomie never deletes a recording on its own. A run, capture, dump or core stays until you delete it. The recording quota only stops new data for a boot; it never removes saved data. See Limits and quota.
- Samples in the library stay until you remove them. Remove keeps the sample’s custody log with a Removed entry; a full purge is a separate action and is recorded too. See Custody log.
- Deleting a VM deletes its configuration, disk and snapshots, but retained run recordings and terminal history are kept.
- Resetting a disk to its base discards the VM’s disk changes, not its recordings.
- Deleting a base is refused while a VM uses it.
- Delete dump and results on a memory dump removes its file and results. An imported dump is only Removed from list; its file stays where it was.
- An imported core is referenced in place. Retain the original file.
Deleting captures, cores and disk dumps
Section titled “Deleting captures, cores and disk dumps”Right-click a row in Core dumps (manual cores, on-exit process cores and imported core results), in the Network capture list (per-run and whole-boot captures) or in the Disks dump list and choose Delete…. A confirmation names the item and its size and says it cannot be undone.
The deletion is done by the app’s backend, only inside the VM’s recording
folders and only at the places the recorder writes these items: paths are
resolved first, and .. and symbolic links are refused. A capture goes with
its summary, its annotation folder and any file derived from it, such as the
<capture>.pcap.view cache. An imported core loses only its results, never the
original file, and an imported disk image’s own file is never deleted. A live
capture, or a capture or core still being written, cannot be deleted.
The boot’s recording quota gets the freed bytes back. Runs that listed the capture or core now read it as Deleted: Run History, Triage counts and Detection (which says “Evidence missing”) follow, and each deletion is an Activity entry. Older Antinomie versions can still read the data directory afterwards.
What is cleaned up automatically
Section titled “What is cleaned up automatically”| What | Rule |
|---|---|
| Archive index cache | Entries unused for 30 days are dropped, and the cache stays under 2 GiB, least recently used first. It is a cache: a damaged one is rebuilt. |
| Terminal scrollback | 10,000 lines per terminal on screen; the saved terminal output of a run is kept whole |
| A boot’s extra disk layer (0.8.0) | Each start seals the disk the boot started from under a fresh empty layer; when the boot is over and the earlier bytes are copied, the layer is merged back down. It is never a snapshot and never shown in Snapshots; a crash leaves it for the next start to finish |
| Finished guest core handles | Released after 180 seconds without access |
| Old activity | The Activity log can be cleared with Clear |
| Disk views | The temporary image of a disk opened in Disks without Keep as dump is deleted when you close the view or start the VM; one left by a crash is removed at the next start, and so is a disk dump that never finished |
| Network view cache | A capture’s <capture>.pcap.view cache is rebuilt when the capture or TShark changes, and deleted with the capture |
Back up safely
Section titled “Back up safely”- Stop the VM.
- Close Antinomie normally. Closing asks the guest to shut down, keeps collecting during shutdown, and then makes the recording durable. A guest that does not stop within the shutdown timeout is forced off and the recording says so.
- Copy the VM’s disk and recording folders, and the data directory’s
bases/and, in 0.8.0,samples/.
Do not move or replace the files of a VM that is running, or delete temporary files of a running boot. Keep the recording folder with the matching VM disk if you may want to reopen the VM’s snapshots.
Remember that recordings can hold secrets from the sample; store backups accordingly. See Safety.