> For the complete documentation index, see [llms.txt](https://help.security.gallagher.com/knowledge-hub/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.security.gallagher.com/knowledge-hub/products/cc-software/configure/archiving-and-backups/archiving-an-overview.md). # Archiving overview Archive Command Centre event history to manage database growth and retain records. Archiving moves events and alarm history out of the SQL database after a period of time. It can run on a schedule or be done manually from Command Centre. Archived events stay searchable inside Command Centre, but searches through them are slower than searches through the live database. *** ### Why every site should archive As a site runs, event data is pushed into the `CCFTEvent` database. Most sites use the default SQL instance installed by the Command Centre installer, which is SQL Express and is limited to 10 GB. Once SQL Express hits that limit, the system can no longer record events and the event trail stops populating. Command Centre raises alarms well before this point, but someone has to see and act on them. Once the database exceeds 10 GB, the site has only two options: * Upgrade to a full version of SQL, or * Remove the `CCFTEvent` database and replace it with a blank one, losing all events in it. Upgrading to full SQL is something some sites cannot afford or will not fund. Replacing the database with a blank one is easy, but loses all events. > **Set archiving up while the database is still under 10 GB.** At that point archiving reduces `CCFTEvent` to a size the SQL instance can manage, and the problem never arises. Auto-archiving should be set up on **all** sites, especially sites left unattended without a dedicated staff member watching the alarms. See [Archiving - Database Information](/knowledge-hub/products/cc-software/configure/archiving-and-backups/archiving-database-information.md) for the SQL Express size caps and what happens when a site does not archive. *** ### What is the default archiving period? By default, archiving removes events older than **90 days** from `CCFTEvent`. This is the recommended setting. Leaving events in the database for an extended time makes it large and unwieldy and risks exceeding the SQL Express limit. ![Command Centre archiving configuration showing the default setting to remove events older than 90 days](https://328339335-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F6bM8WhlBE9BYizPWJaPN%2Fuploads%2Fgit-blob-6cf00e1dba1bc6f19eed996af38ac6db009e0fa7%2FSECHUB-CCS-ARCH-01-archive-config-default-90-days.png?alt=media) Archived events can still be browsed from within Command Centre. They are unreadable by any other system and are tamper-resistant. Searches through archived events are slower than searches through the live database. *** ### How do you archive manually, and how is data integrity protected? 1. In Command Centre, go to **File > Archives**. 2. Specify a date up to which events and image sequences are to be archived. **The date must precede the date of the oldest unprocessed alarm.** 3. The Archiver creates an archive file for each day, working backwards. The date you specify only controls what is removed from `CCFTEvent`. *** ### Data integrity (CRC checksums) To ensure data integrity, the Archiver and Restorer use **32-bit CRC checksums**: * Each file has a CRC checksum at the end, and each object in the file has its own CRC checksum. * For each object there are two CRC calculations: one for the object itself, and one running CRC for the whole file. The running total updates after each object is written. The individual (non-seeded) CRC is written immediately after its object; the running CRC is written at the end of the file. * If an individual archive file is modified, it no longer matches the database and the report flags possible tamper, for example: *"This report may be incomplete - The archive file SECCDX101\_2018-08-03\_001.FTArchive used in this report was tampered."* *** ### What is inside an archive file? A late event can arrive after a day has passed. For example, a controller that was offline for a few days offloads old events when it reconnects. So each archive file contains only a **single day's** events. There may be multiple files for one day, one per archive operation that found events on that day. When an archive runs, the Archiver stores in `CCFTCentral` the information needed to restore: the archive name (the date the file covers), the date of the events stored, the location of the archived files, and a unique file ID. On a restore, the system maps the requested days to the archive files it needs to read. ### How is an archive file named? ``` [EventDate]_[UniqueID]_[Type].FTArchive ``` * `[EventDate]`: date of the events in the file, `YYYY-MM-DD`. For image sequences, the date of the first trigger. * `[UniqueID]`: a 4-character suffix starting at `0000`, incrementing by one per file. * `[Type]`: `Event` or `Image`, depending on whether the file holds events or image sequences. *** ## How to import orphaned archive files? If the system is restored from backup (for example, after a failure) and an archive operation ran between that backup and the next, the restored `CCFTCentral` will not know about those archived files. Their details must be added back so the events and image sequences are known to the system, by directly importing the archive files. The **`ArchiveUpdater.exe`** utility does this. *** 🔗 **Related** * [Archiving - Database Information](/knowledge-hub/products/cc-software/configure/archiving-and-backups/archiving-database-information.md). SQL Express size caps and what happens without archiving. * [Backups - An Overview](/knowledge-hub/products/cc-software/configure/archiving-and-backups/backups-an-overview.md). Protecting the configuration database. * [Databases - Sizes and Examples](/knowledge-hub/products/cc-software/reference/databases-sizes-and-examples.md). Sizing the event database and how often to archive. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.security.gallagher.com/knowledge-hub/products/cc-software/configure/archiving-and-backups/archiving-an-overview.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.