A method for completely deleting a file based on a network disk file system

Abstract

The application discloses a kind of based on file system of network disk file complete security deletion method, belong to network storage and data security technical field.The application realizes the safe deletion of file by a multi-stage, asynchronous process.First, according to the deletion state flag in database extraction file list to be deleted;Then, the main metadata and associated metadata of the file to be deleted are moved from the main storage space to the backup metadata space;Then, the corresponding stream data in object storage is moved to the backup bucket;After a configurable waiting period, the stream data in the backup bucket and the metadata in the backup space are completely deleted by an asynchronous task, and the whole process is logged.The application uses a two-stage deletion mechanism of "move-wait-destroy", which ensures that the file can be recovered during the waiting period, and completely removes the data at the physical and logical levels after the waiting period, significantly improving the security, reliability and user experience of the network disk system.

Description

Technical Field

[0001] This invention relates to the field of network storage and data security technology, specifically to a method for the complete and secure deletion of files based on a cloud storage file system. Background Technology

[0002] With the development of cloud computing and big data technologies, cloud storage has become an important tool for individual and enterprise users to store, synchronize, and share data. In traditional cloud storage file systems, when a user performs a deletion operation, the system typically only adds a "deleted" mark to the file system metadata, without immediately erasing the actual physical data on the storage medium. While this logical deletion method can quickly reclaim space and support recycle bin functionality, it poses serious security risks. Malicious attackers or technicians could potentially recover these files marked as deleted using underlying tools, leading to the leakage of sensitive information.

[0003] On the other hand, if an immediate physical deletion strategy is adopted, once a user accidentally deletes an important file, it will be unrecoverable, causing irreparable damage. Some existing secure deletion methods, such as repeatedly overwriting data, will generate huge I / O overhead and performance degradation in large-scale distributed object storage applications, making them impractical.

[0004] Therefore, designing a method for completely and securely deleting files that can prevent data from being maliciously recovered, provide a buffer period for accidental deletion, and minimize the impact on system performance is a technical challenge that urgently needs to be solved in the field of cloud storage file systems. Summary of the Invention

[0005] The purpose of this invention is to overcome the shortcomings of the prior art and provide a method for the complete and secure deletion of files based on a cloud storage file system, achieving efficient, secure and reliable deletion of cloud storage files.

[0006] The objective of this invention is achieved through the following technical solution:

[0007] A method for completely and securely deleting files based on a cloud storage file system includes:

[0008] Deletion Request and Tagging Phase: The cloud storage application server receives deletion requests, parses the deletion requests, and changes the status field of the file to be deleted in the master metadata database to "to be deleted".

[0009] Data isolation and migration phase:

[0010] Extract the master metadata of all files in the pending deletion state and copy it to the backup data table in the backup metadata space to generate backup metadata, and add backup time and planned clearing time fields to each backup metadata record;

[0011] Search the master metadata database for the associated metadata of the file to be deleted, move the found associated metadata to the corresponding backup data table in the backup metadata space, and after the master metadata and all associated metadata have been successfully migrated to the backup space, completely delete the original records in the master metadata database.

[0012] The object storage system moves the streaming data corresponding to the metadata located in the primary bucket to the backup bucket according to the same path rules. After the move is completed, the object storage system automatically deletes the original objects in the primary bucket.

[0013] Waiting and Cleanup Phase: Set a scheduled task to put the file into a waiting state for complete deletion. After the waiting state for complete deletion has passed, asynchronously and completely delete the stream data corresponding to the file in the list to be destroyed. After deletion is completed, asynchronously and completely delete the metadata and associated metadata in the corresponding backup data table.

[0014] Auditing and logging phase: Log the data information of the deleted file at key nodes in its entire lifecycle, generate structured log information, archive the log information and save it for a specified period of time.

[0015] Furthermore, the cloud storage application server receives and parses the deletion request, and changes the status field of the file to be deleted in the master metadata database to "pending deletion," specifically including:

[0016] Users initiate deletion requests for specified files or folders to the cloud storage application server through the client. The deletion request includes user identity information and file unique identifier FileID.

[0017] The cloud storage application server verifies the user's identity and the user's operation permissions on the file based on the user's identity information and the file's unique identifier FileID, and determines whether the user who initiated the deletion request is the owner or has deletion permissions.

[0018] After the permission verification is passed, the cloud storage application server locates and queries the corresponding record of the file in the master metadata database based on the file's unique identifier FileID;

[0019] The cloud storage application server updates the value of the status field in the queried record from active to pending_delete, and records the current timestamp to the deletion request time field delete_request_time.

[0020] Furthermore, the step of extracting the master metadata of all files in the state to be deleted and copying it to the backup data table in the backup metadata space to generate backup metadata, and adding backup time and planned cleanup time fields to each backup metadata record, specifically includes:

[0021] Deploy a deletion processor to scan the master metadata database at a fixed frequency.

[0022] Query and batch extract all records in the tbl_file_metadata table whose status field value is pending_delete, forming a list of files to be processed;

[0023] Read each file in the list of files to be processed, identify the complete master metadata of the file, which includes FileID, file name, file size, creation time, owner ID, original storage path, and unique key ObjectKey in object storage;

[0024] Create a new record in the backup data table tbl_backup_metadata in the backup metadata space, and copy the read master metadata completely to the new record in the backup data table to generate backup metadata;

[0025] At the same time, additional fields are generated and populated for the backup metadata record, including backup time and scheduled purge time.

[0026] Furthermore, the value of the scheduled_purge_time is calculated based on a preset deletion retention strategy.

[0027] Furthermore, the process of searching for the associated metadata of files in the master metadata database that are to be deleted, moving the found associated metadata to the corresponding backup data table in the backup metadata space, and after the master metadata and all associated metadata have been successfully migrated to the backup space, completely deleting the original records in the master metadata database, specifically includes:

[0028] Search the master metadata database for associated metadata of files in the pending deletion state. Associated metadata includes historical version information tbl_file_versions, user comments tbl_file_comments, shared links tbl_share_links, and access control lists tbl_acls.

[0029] Move all the retrieved related metadata from the corresponding table in the primary database to the corresponding backup table in the backup metadata space, and ensure that the new backup related metadata is correctly associated with the created backup primary metadata record;

[0030] After confirming that the master metadata and all associated metadata have been successfully migrated to the backup space, the original records of tbl_file_metadata in the master metadata database are completely deleted.

[0031] Furthermore, the object storage system moves the streaming data corresponding to the metadata located in the primary bucket to the backup bucket according to the same path rules. After the move is completed, the object storage system automatically deletes the original objects in the primary bucket, specifically including:

[0032] The delete processor initiates a move operation to the underlying object storage system based on the unique key ObjectKey in the object storage in the metadata. The move operation is essentially a copy operation plus a delete operation.

[0033] The object storage system copies the streaming data corresponding to the unique key ObjectKey in the object storage located in the primary_bucket to a backup_bucket; the object path in the backup_bucket is designed to include deletion date information.

[0034] After confirming that the object has been successfully copied to the backup bucket, the object storage system automatically deletes the original object from the primary bucket.

[0035] Furthermore, the scheduled task puts the file into a state awaiting complete deletion. After the file enters the state of awaiting complete deletion, the corresponding stream data of the file in the list to be destroyed is asynchronously and completely deleted. After deletion, the metadata and associated metadata in the corresponding backup data table are asynchronously and completely deleted, specifically including:

[0036] Deploy a Data Purger to query the backup data table tbl_backup_metadata at low frequency, identify the value of the scheduled_purge_time field, filter out all records with a scheduled_purge_time earlier than or equal to the current time, and generate a list to be destroyed; the files corresponding to records with a scheduled_purge_time later than the current time enter a silent waiting state for complete deletion.

[0037] For each item in the list to be destroyed, the data destroyer first sends an asynchronous deletion request to the object storage system in batches to delete the corresponding streaming data object in the backup bucket.

[0038] After confirming through polling or callback mechanisms that the streaming data object has been physically deleted or has entered an unrecoverable deletion queue, proceed to the next step.

[0039] After the streaming data is confirmed to be deleted, the data destroyer completely deletes the backup data table tbl_backup_metadata and the corresponding records in all related backup-related metadata tables in a single database transaction.

[0040] Furthermore, during the waiting period for complete deletion, an administrator or user with advanced privileges can restore the original files from the backup data through a specific transmission interface after specific verification.

[0041] Furthermore, the key milestones in the entire lifecycle of the deleted file include:

[0042] First log node: When a user requests to delete a file, record the operator, IP address, time, FileID, and filename information;

[0043] Second log node: When file metadata and streaming data are deleted and the processor is migrated to the backup space, the migration time, source path, and destination path are recorded.

[0044] The third log node records the deletion time, FileID, filename, and proof of successful destruction when the file is completely deleted by the data destroyer.

[0045] The beneficial effects of this invention are:

[0046] 1) Security: Existing logical deletion techniques (such as placing files in the recycle bin) only mark the data; the physical data remains in its original storage location, posing a significant security risk of malicious recovery and data leakage. This invention completely migrates the metadata and streaming data of the file to be deleted to a backup space isolated from the main system—namely, a backup metadata space and a backup bucket—and ultimately performs physical destruction, achieving thorough data erasure and fundamentally eliminating the possibility of data residue and unauthorized recovery.

[0047] 2) Reliability: While the other extreme technique, "immediate physical deletion," is secure, it is extremely unfriendly to user error; once accidentally deleted, the data will be permanently lost. This invention uniquely sets a configurable waiting time for complete deletion, essentially providing users with a period of remorse or a cooling-off period. During this period, isolated data can still be recovered, effectively preventing catastrophic consequences due to accidental deletion and greatly improving system reliability and user experience. This method perfectly balances the core requirements of "irreversible" security and "recoverable" reliability through a two-tiered strategy of "isolation migration + timed destruction." Attached Figure Description

[0048] Figure 1 A flowchart illustrating a method for the complete and secure deletion of files based on a cloud storage file system;

[0049] Figure 2 This is a system architecture diagram related to a method for the complete and secure deletion of files based on a cloud storage file system. Detailed Implementation

[0050] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0051] See Figures 1-2 The present invention provides a technical solution:

[0052] A method for completely and securely deleting files based on a cloud storage file system, such as... Figure 1 include:

[0053] Deletion Request and Tagging Phase: The cloud storage application server receives the deletion request, parses it, and changes the status field of the file to be deleted in the master metadata database to "pending deletion." This specifically includes:

[0054] S11. The user initiates a deletion request for a specified file or folder to the cloud storage application server through the client. The deletion request includes user identity information and file unique identifier FileID. The client includes a web interface, a PC client, and a mobile app.

[0055] S12. The cloud storage application server verifies the user's identity and the user's operation permissions on the file based on the user's identity information and the file's unique identifier FileID, and determines whether the user who initiated the deletion request is the owner or has deletion permissions.

[0056] S13. After the permission verification is passed, the cloud storage application server locates and queries the record corresponding to the file in the master metadata database tbl_file_metadata based on the file's unique identifier FileID.

[0057] S14. The cloud storage application server updates the value of the `status` field in the queried record from `active` to `pending_delete`, and records the current timestamp to the `delete_request_time` field. This operation is completed within a database transaction, ensuring atomicity. At this point, the target file to be deleted is no longer visible to the user, but all data still exists in the main storage database.

[0058] Data isolation and migration phase:

[0059] S21. Extract the master metadata of all files in the pending deletion state and copy it to the backup data table in the backup metadata space. Generate backup metadata and add backup time and planned cleanup time fields to each backup metadata entry. Specifically, this includes:

[0060] S211. Deploy a Deletion Processor to scan the master metadata database at a fixed frequency, query and batch extract all records in the tbl_file_metadata table whose status field value is pending_delete, forming a list of files to be processed; the Deletion Processor deployed in the background is a scheduled task or a resident service, which can be set to scan the master metadata database once every 5 minutes.

[0061] S212. Read each file in the list of files to be processed and identify the complete master metadata of the file. The master metadata includes FileID, file name, file size, creation time, owner ID, original storage path, and unique key ObjectKey in object storage.

[0062] S213. Create a new record in the backup data table tbl_backup_metadata in the backup metadata space, and copy the read master metadata completely to the new record in the backup data table to generate backup metadata.

[0063] S214. Simultaneously, additional fields are generated and populated for the backup metadata record. These additional fields include the backup time (backup_time) and the scheduled purge time (scheduled_purge_time). In a specific embodiment, the value of the scheduled purge time (scheduled_purge_time) is calculated based on a preset deletion retention policy, such as setting the retention period to 30 days.

[0064] S22. Search the master metadata database for the associated metadata of the file in the state to be deleted, move the searched associated metadata to the corresponding backup data table in the backup metadata space, and after the master metadata and all associated metadata have been successfully migrated to the backup space, completely delete the original records in the master metadata database, specifically including:

[0065] S221. Search the master metadata database for the associated metadata of the file in the state to be deleted. The associated metadata includes historical version information tbl_file_versions, user comments tbl_file_comments, shared links tbl_share_links, and access control lists tbl_acls.

[0066] S222. Move (copy and delete) all the queried related metadata from the corresponding table in the master database to the corresponding backup table in the backup metadata space (such as `tbl_backup_versions`, `tbl_backup_share_links`), and ensure that the new backup related metadata is correctly associated with the created backup master metadata record.

[0067] S223. After confirming that the master metadata and all associated metadata have been successfully migrated to the backup space, completely delete the original record of tbl_file_metadata in the master metadata database. This step ensures that the file is logically completely removed from the master system.

[0068] S23. The object storage system moves the streaming data corresponding to the metadata located in the primary bucket to the backup bucket according to the same path rules. After the move is completed, the object storage system automatically deletes the original objects in the primary bucket. Specifically, this includes:

[0069] S231. The delete processor initiates a MOVE operation to the underlying object storage system based on the unique key ObjectKey in the object storage in the metadata. The MOVE operation is essentially a COPY plus DELETE operation. The underlying object storage system includes AWS S3 and MinIO.

[0070] S232. The object storage system copies the stream data (file content) corresponding to the unique key ObjectKey in the object storage located in the primary bucket to a backup bucket. The object path in the backup bucket is designed to include deletion date information. The backup bucket is a storage device with more isolation and stricter access policies than the primary bucket. The object path in the backup bucket is designed to include deletion date and other information for easy management, such as `backup_bucket / 2025 / 10 / 15 / ObjectKey`.

[0071] S233. After confirming that the object has been successfully copied to the backup bucket, the object storage system automatically deletes the original object from the primary bucket. At this point, the file's metadata and streaming data have all been migrated to the isolated backup area.

[0072] Waiting and Cleanup Phase: A scheduled task is set to put files into a waiting state for complete deletion. After the waiting state is complete, the corresponding stream data for the files in the list to be destroyed is asynchronously and completely deleted. After deletion, the metadata and associated metadata in the corresponding backup data table are asynchronously and completely deleted, specifically including:

[0073] S31. Deploy a Data Purger to query the backup data table tbl_backup_metadata at a low frequency. The Data Purger is a higher-priority scheduled task that identifies the value of the scheduled_purge_time field, filters out all records whose scheduled_purge_time is earlier than or equal to the current time, and generates a list to be destroyed. The files corresponding to records whose scheduled_purge_time is later than the current time enter a silent waiting state for complete deletion. During the waiting state for complete deletion, an administrator or user with advanced privileges can restore the original files from the backup data through a specific transmission interface after specific verification.

[0074] S32. For each item in the list to be destroyed, the data destroyer first sends asynchronous deletion requests to the object storage system in batches to delete the corresponding streaming data object in the backup bucket. These requests are placed in a high-priority queue and executed by the storage backend.

[0075] S33. After confirming through polling or callback mechanisms that the stream data object has been physically deleted or has entered an unrecoverable deletion queue, proceed to the next step; to prevent accidents, a retry mechanism can be set.

[0076] S34. After the stream data is confirmed to be deleted, the data destroyer completely deletes the backup data table tbl_backup_metadata and the corresponding records in all related backup-related metadata tables in a single database transaction.

[0077] Auditing and logging phase: Log the data information of the deleted file at key nodes in its entire lifecycle, generate structured log information, archive the log information and save it for a specified period of time.

[0078] Furthermore, the key milestones in the entire lifecycle of the deleted file include:

[0079] First log node: When a user requests to delete a file, record the operator, IP address, time, FileID, and filename information;

[0080] Second log node: When file metadata and streaming data are deleted and the processor is migrated to the backup space, the migration time, source path, and destination path are recorded.

[0081] The third log node records the deletion time, FileID, filename, and proof of successful destruction when the file is completely deleted by the data destroyer.

[0082] The method system of this invention involves a user client, a cloud storage application server, a central log system, a deletion processor, a data destroyer, a main metadata database, and a backup metadata space. The main object storage and backup object storage are illustrated in the system architecture diagram below. Figure 2 As shown, this invention employs a two-tiered deletion mechanism of "move-wait-destroy," ensuring file recovery during the waiting period and achieving complete physical and logical erasure of data after the waiting period. This significantly improves the security, reliability, and user experience of the cloud storage system.

[0083] This invention provides a complete data isolation and migration mechanism. First, the file is marked as deleted. Then, all components of the file (including primary metadata, all associated metadata (such as historical versions, shared links, etc.), and streaming data in object storage) are completely moved from the primary storage system to a logically and physically isolated backup storage system. This method ensures the integrity of the deletion operation (covering all types of data) and its isolation (migrating to a dedicated backup metadata space and backup bucket). This mechanism, by thoroughly removing the data to be deleted from the active production environment, achieves secure cleanup and architectural simplification of the primary system without immediately destroying the data. This is the foundation for subsequent secure deletion and high system performance.

[0084] This invention also provides an asynchronous, non-blocking data termination and destruction mechanism based on a time-based strategy. The final physical deletion operation is completely decoupled from the user's foreground deletion request in terms of time and execution. An independent background task, after a preset waiting period, asynchronously and step-by-step (first stream data, then metadata) performs a thorough cleanup. The "waiting period" provides the possibility of data recovery, while "asynchronous destruction" ensures that resource-intensive physical deletion operations do not impact the real-time performance of the main system. This approach, which separates high-load tasks from the user interaction process, is a key technological innovation that ensures the stability and efficiency of large-scale cloud storage systems under high-concurrency deletion requests.

[0085] The above description is merely a preferred embodiment of the present invention. It should be understood that the present invention is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the concept described herein through the above teachings or related technologies or knowledge. Modifications and variations made by those skilled in the art that do not depart from the spirit and scope of the present invention should be within the protection scope of the appended claims.

Claims

1. A method for file complete security deletion based on a network disk file system, characterized in that, Comprise: Deletion request and marking phase: the network disk application server receives the deletion request, parses the deletion request, changes the state field of the file to be deleted in the main metadata database to the state to be deleted; Data isolation and migration phase: Extract the main metadata of all files in the state to be deleted and copy it to the backup data table in the backup metadata space, generate backup metadata, and add backup time and scheduled cleanup time fields to each backup metadata; Search for associated metadata of files in the state to be deleted in the main metadata database, move the searched associated metadata to the corresponding backup data table in the backup metadata space, and after successfully migrating the main metadata and all associated metadata to the backup space, delete the original record in the main metadata database; The object storage system moves the stream data corresponding to the metadata in the main storage bucket to the backup storage bucket according to the same path rule, and after the movement is completed, the object storage system automatically deletes the original object in the main storage bucket; Waiting and cleaning phase: set a timing task to make the file enter the waiting for complete deletion state, and after the waiting for complete deletion state, asynchronously delete the stream data corresponding to the file in the list to be destroyed, and after the deletion is completed, asynchronously delete the metadata and associated metadata in the corresponding backup data table; Audit and log recording phase: log record the data information at the key nodes in the entire life cycle of the deleted file, generate structured log information, archive and save the log information for a specified period of time.

2. The method for file complete security deletion based on network disk file system according to claim 1, characterized in that: The network disk application server receives the deletion request, parses the deletion request, and changes the state field of the file to be deleted in the main metadata database to the state to be deleted, specifically comprising: The user initiates a deletion request to the network disk application server through the client for a specified file or folder, and the deletion request includes user identity information and a file unique identifier FileID; The network disk application server verifies the user identity and the user's operation permission according to the user identity information and the file unique identifier FileID, and judges whether the user initiating the deletion request is the owner or has the deletion permission; After the permission verification is passed, the network disk application server locates and queries the record corresponding to the file in the main metadata database according to the file unique identifier FileID; The network disk application server updates the value of the status status field in the queried record from active to pending_delete, and records the current timestamp in the delete_request_time field.

3. The method for file complete security deletion based on network disk file system according to claim 2, characterized in that: The extraction of the main metadata of all files in the state to be deleted and the copying to the backup data table in the backup metadata space, the generation of backup metadata, and the addition of backup time and scheduled cleanup time fields to each backup metadata, specifically comprising: Deploy a deletion processor Deletion Processor to scan the main metadata database at a fixed frequency, Query and batch extract all records in the tbl_file_metadata table with the value of the status status field as pending_delete, forming a list of files to be processed; reading each file in the list of files to be processed, identifying the complete primary metadata of the file, the primary metadata including FileID, filename, file size, creation time, owner ID, original storage path, and unique key ObjectKey in the object storage; creating a new record in the backup data table tbl_backup_metadata of the backup metadata space, copying the read primary metadata to the new record of the backup data table, and generating backup metadata; At the same time, generate and fill in additional fields for the backup metadata record, including backup time backup_time and scheduled purge time scheduled_purge_time.

4. The method for completely deleting a file based on a network disk file system according to claim 3, characterized in that: The value of the scheduled purge time scheduled_purge_time is calculated according to the preset deletion retention policy.

5. The method for file complete security deletion based on network disk file system according to claim 4, characterized in that: The associated metadata of the file to be deleted is searched in the primary metadata database, and the searched associated metadata is moved to the corresponding backup data table in the backup metadata space. After the primary metadata and all associated metadata are successfully migrated to the backup space, the original record in the primary metadata database is completely deleted, specifically including: searching the associated metadata of the file to be deleted in the primary metadata database, the associated metadata including historical version information tbl_file_versions, user comments tbl_file_comments, shared links tbl_share_links, and access control list tbl_acls; move all the associated metadata from the corresponding table in the primary database to the corresponding backup table in the backup metadata space, and ensure that the new backup associated metadata is correctly associated with the created backup primary metadata record; After confirming that the primary metadata and all associated metadata have been successfully migrated to the backup space, the original record of tbl_file_metadata in the primary metadata database is completely deleted.

6. The method for completely deleting a file based on a network disk file system according to claim 5, characterized in that: The object storage system moves the stream data corresponding to the metadata in the primary storage bucket to the backup storage bucket according to the same path rule. After the moving is completed, the object storage system automatically deletes the original object in the primary storage bucket, specifically including: The deletion processor initiates a move MOVE operation to the underlying object storage system according to the unique key ObjectKey in the metadata, and the move MOVE operation is essentially a copy COPY plus a delete DELETE operation; The object storage system copies the stream data corresponding to the unique key ObjectKey in the object storage in the primary storage bucket primary_bucket to a backup storage bucket backup_bucket. The object path in the backup bucket backup_bucket is designed to include deletion date information; After confirming that the object has been successfully copied to the backup storage bucket backup_bucket, the object storage system automatically deletes the original object in the primary storage bucket primary_bucket.

7. The method for file complete security deletion based on network disk file system according to claim 6, characterized in that: The setting timing task makes the file enter the waiting for complete deletion state, and after the waiting for complete deletion state, the stream data corresponding to the file in the to-be-destroyed list is asynchronously completely deleted, and after the deletion is completed, the metadata and associated metadata in the corresponding backup data table are asynchronously completely deleted, and the specific operations include the following operations: Deploy a data destroyer Data Purger to run a query backup data table tbl_backup_metadata table at a low frequency, identify the value of the scheduled_purge_time field, filter out all records whose scheduled_purge_time is earlier than or equal to the current time, and generate a to-be-destroyed list; the records whose scheduled_purge_time is later than the current time correspond to the files entering the silent waiting for complete deletion state; For each to-be-destroyed item in the to-be-destroyed list, the data destroyer first sends a batch of asynchronous deletion requests to the object storage system to delete the corresponding stream data object in the backup storage bucket backup_bucket; After confirming that the stream data object has been physically deleted or has entered an unrecoverable deletion queue through a polling or callback mechanism, the next step is performed; After the stream data is confirmed to be deleted, the data destroyer completely deletes the corresponding records in the backup data table tbl_backup_metadata and all related backup associated metadata tables in a single database transaction.

8. The method for file complete security deletion based on network disk file system according to claim 1, characterized in that: During the waiting for complete deletion state, an administrator or user with high-level permissions can recover the original file from the backup data through a specific transmission interface after specific verification.

9. The method for file complete security deletion based on network disk file system according to claim 7, characterized in that: The key nodes in the whole life cycle of the deleted file include: The first log node: when a user requests to delete a file, the operation person, IP address, time, FileID, and file name information are recorded; The second log node: when the file metadata and stream data are migrated to the backup space by the deletion processor, the migration time, source path, and target path are recorded; The third log node: when the file is completely cleared by the data destroyer, the clearance time, FileID, file name, and proof of successful destruction are recorded.

Images