Feature preview
The backup range should be determined according to 'any missing data during recovery counts as a failure': only backing up the database will result in the loss of uploaded images and attachments, and only backing up files will result in the loss of article structure, categories, and user data. AnQiCMS supports backing up data including static files together, combining the two types of content into a single operation. The availability of the backup should be determined by recovery drills, not by file size; the backup is a site-wide operation, and permissions should be controlled according to controlled actions.
Should the backup include uploading files and databases together? It should be counted in one range. The state of the content system is naturally split into two halves: the database stores structured facts, article content, categories, tags, user and site configuration; the upload directory stores static files, images, attachments, and generated static products. Only backing up half of it will inevitably be missing things during recovery, so 'counting them together' is not a convenient way, but the premise of being able to truly recover.
Database loss is bulk loss: a single mistake or injection incident may take away the structure of several years of articles at once, and it is very difficult to restore from elsewhere. Static file loss is degradation page by page: the articles are still there, but the pictures are cracked, attachments are invalid, and the front-end looks like it has been moved. The cost of repair for both is completely different, the former relies on backup to restore, and the latter can only be retransmitted in the absence of backup, with the amount of manual work increasing linearly with the scale of the site.
There is still a third state often overlooked: the intermediate state in the content lifecycle. Documents are divided into formal documents, drafts, pending release, and recycling bin, deleting a formal document is to move it to the recycling bin instead of physical deletion, and drafts with the preview parameter can be previewed. The existence of the recycling bin and drafts means that 'undeleteable' only applies within the site; once a full-site rebuild or migration is needed, these unissued contents should also be included in the backup range, otherwise, the restored content will only be half of the history.
AnQiCMS backup and restore supports data backup and recovery (including static files), bringing structured data and uploaded files together in one operation to avoid common mismatches such as 'backed up the database but lost the images'. To determine if your backup is complete, you can use a checklist to compare: articles and their fields, categories and tags, user-uploaded media, site configuration, templates and static products. Any item on the checklist that cannot be rebuilt from another location should be within the scope of the backup.
It should be reminded that backup and content layer protection are not the same thing. Operations such as full site replacement and navigation adjustment change the content in the database, and a rollback point is also needed in case of problems, so it is a low-cost insurance to make a backup before executing such batch operations.
Only verifying that 'the backup file was generated' is meaningless, you need to verify that 'it can run in the new environment'. The feasible drill is divided into three steps: copying the backup to a clean machine and restoring it, checking if the number of articles and the front-end routing are consistent with the source site; randomly selecting a few old articles with pictures and attachments to confirm that static files can be accessed normally; checking if the login and backend permissions have been restored to an operable state. The drill should leave time to record it, and the time taken to recover determines the actual loss on the day of the accident.
The drill in a multi-site scenario still needs to verify an additional item: whether the content, configuration, and permissions between sites are isolated, and whether restoring a single site will overwrite data from other sites. Multi-site management itself is a form designed for multiple independent sites, and the backup granularity should match this structure.
The backup will take away all the data of the entire station, so its risk is equivalent to that of a portable sensitive asset. The reasonable approach is to list the backup as a controlled operation: who can trigger it, in which environments it can be triggered, and where the product is placed. AnQiCMS's MCP interface sets the exposure range based on the intent domain, with operations such as backup, upgrade, and multi-site as default off, requiring explicit enablement, which is exactly what has made the mechanism of 'not everyone can restore the entire station data'. On the storage side, access should be restricted, and the backup product should not be placed in a location that can be directly accessed by the public network.
Is it feasible to only back up the database and images by object storage for separate synchronization?Feasible, but it must meet two conditions: the synchronization of object storage has versioning and recycling capabilities, and the recovery process can align the data on both sides to the same time point. Otherwise, it is easy to appear that the article points to an image that does not exist.
How to determine the backup frequency?Determine it according to the frequency of content changes, not by time. For sites that publish or collect in batches multiple times a day, the interval should be shortened; for sites mainly composed of static pages, low frequency plus 'manual backup before major operations' is more practical.
How to confirm that the backup can really be restored?Regularly conduct recovery drills: Restore once in an isolated environment, verify the number of articles, the availability of picture attachments, and back-end login, and record the recovery time. Backups that have not been tested through drills should not be considered available.
Preview
AnQiCMS provides AI writing features starting from April 2023, stringing together repetitive content production processes: automatically generating tags when creating articles, automatically assigning images based on the title content, and generating TDK keyword descriptions for the title. It comes with built-in AI Chat and a skill set covering content, SEO, operations, and other domains, which can be arranged and called by an intelligent agent, with humans responsible for选题 and fact verification.
Preview
AI painting, automatic tagging, and AI TDK save the three stages of manual work in the content production process: picture matching, classification, title, and description writing. Content sites with a large volume of postings and a fixed number of human resources have the most direct benefits, while personal blogs and low-frequency sites have limited benefits. Sensitive word filtering and content review at the intake level cannot be omitted, and AnQiCMS configures the generation and review in the same process flow.
Preview
When AI completes the manuscript and simultaneous human review, the quality is controlled by three layers separately: the generation layer is responsible for output and automatic labeling, the rule layer uses sensitive word filtering and keyword replacement to intercept certain issues first, and the manual layer relies on draft preview and pending release status for control. The sequence is that the rule layer takes effect before the manual layer, and humans only deal with judgment issues left by the rule layer, and only mass output can sustain.
