Private ipfs-based data storage apparatus and method

Abstract

An IPFS-based data storage device according to an embodiment of the present invention comprises: a communication unit; a memory storing at least one instruction and data replication policy information; and a processor that performs an operation according to the instruction, wherein the processor may be configured to store a data source by distributing replication to a plurality of nodes according to a data replication policy on a private IPFS network, detect the disaster when a disaster occurs at least one of the nodes, and automatically re-replicate and recover the lost data based on the fragment of the data source stored in the surviving node.

Description

Technology Field

[0001] The present invention relates to the field of distributed storage technology, and more specifically, to a private IPFS-based data storage device and method that secure enterprise-grade performance and reliability by storing data sources by distributing replication based on policies in a private IPFS network environment and providing a disaster recovery function that automatically re-replicates lost data based on data fragments stored in surviving nodes in the event of a node failure or geographical disaster. Background Technology

[0002] IPFS, a distributed file system, can verify file integrity by utilizing content address-based CIDs, but it has the following limitations due to its structural characteristics based on a public network.

[0003] First, public IPFS lacks a system to guarantee node availability; therefore, if multiple nodes go offline, data sources cannot be accessed, and it does not provide the concept of disaster recovery.

[0004] Second, since data encryption is not provided by default, stored data can be exposed in plain text, and access control features are also not provided, making it difficult to meet the security requirements demanded in an enterprise environment.

[0005] Third, because there is no function to manage replication factors based on data replication policies, it is impossible to manage the actual number of replicas, and it is impossible to ensure consistency and fault tolerance.

[0006] Fourth, predictable performance is not provided when storing and querying large-scale files, and automatic recovery is not provided in the event of a node failure. Prior art literature

[0007] Published Patent Application No. 10-2022-0075272 The problem to be solved

[0008] The objective of the present invention is to provide a storage technology that stores a data source in a private IPFS network by distributing replication across multiple nodes according to a data replication policy, and ensures that data is not lost even in the event of a node failure or disaster.

[0009] In addition, the objective of the present invention is to provide a self-healing disaster recovery technology that automatically re-replicates original data fragments from surviving nodes to recover data in the event of a disaster, such as a node failure or data center failure.

[0010] In addition, the objective of the present invention is to provide enterprise-grade security features including integrity verification using CID and trust anchors, multi-layered access control using Bearer Tokens, Swarm Keys, and TLS, and TimescaleDB-based audit logs.

[0011] In addition, the objective of the present invention is to provide enterprise storage-level policy-based data management functions, such as automatic replication factor maintenance, removal of unnecessary replicas, lifecycle policy-based selective recovery, and tenant-level policy isolation.

[0012] In addition, the objective of the present invention is to provide IPFS-based storage technology that optimizes large-capacity file upload and retrieval performance through a cluster composed of high-performance servers and a low-latency network, and enables operation without performance degradation during disaster recovery. means of solving the problem

[0013] An IPFS-based data storage device according to an embodiment of the present invention for solving the above problem comprises: a communication unit; a memory storing at least one command and data replication policy information; and a processor that performs an operation according to the command. The processor selects a replication target node and a deployment target node by considering a replication factor, a regional distribution policy, the remaining storage capacity of the node, and a load state on a private IPFS network, and stores a data source by distributing and replicating it to a plurality of nodes according to the data replication policy information, detects the disaster when a disaster occurs at least one of the nodes, designates a surviving node as the original supply node when a disaster occurs, and designates a new node or a recovery target node as the target node, recovers the lost data block by receiving it again from the original supply node and automatically re-replicates it, sets a retention period, a destruction schedule, and version management on a file, bucket, or tenant basis according to the data lifecycle policy, and performs selective recovery by applying the lifecycle policy when a disaster is recovered.

[0014] In an embodiment, the processor is characterized by setting a replication factor (RF) of a data source based on the data replication policy, automatically performing additional replication when the actual number of replicas is less than the replication factor, and removing unnecessary replicas when it exceeds the factor to maintain consistency.

[0015] In an embodiment, the processor is characterized by encrypting and storing the data source, re-replicating the encrypted data source fragment from a surviving node during disaster recovery, and checking for tampering by comparing the Content Identifier (CID) with a trusted anchor to verify integrity after recovery.

[0016] In an embodiment, the processor is characterized by being able to monitor node failures in real time through a Pin orchestrator upon disaster detection and perform uninterrupted recovery in the event of a disaster by replicating data sources between geographically separated data centers.

[0017] delete

[0018] In an embodiment, the processor is characterized by applying a multi-layered access control technique to allow only authorized users to access data via Bearer Token, Swarm Key, and TLS, and by providing an auditing function by recording access logs in TimescaleDB during the disaster recovery process.

[0019] In an embodiment, the processor is characterized by supporting file-level priority recovery during disaster recovery to minimize recovery time to time (RTO), and by being able to perform selective recovery through CID-based addressing and a dedicated gateway.

[0020] In an embodiment, the processor is characterized by applying policy isolation on a tenant basis to independently set replication, encryption, lifecycle, and geolocation policies, and maintaining tenant-specific isolated policies during disaster recovery.

[0021] In an embodiment, the processor is characterized by optimizing data upload and query performance through a cluster composed of a high-performance server and a low-latency network, and performing automatic recovery without performance degradation during disaster recovery.

[0022] An IPFS-based data storage method according to an embodiment of the present invention for solving the above problem comprises: a step in which a processor selects a replication target node and a deployment target node by considering a replication factor, a regional distribution policy, the remaining storage capacity of the node, and a load state on a private IPFS network, and stores a data source by distributing and replicating it to a plurality of nodes according to data replication policy information; a step in which the processor detects the disaster when a disaster occurs in at least one node among the plurality of nodes; and a step in which, when a disaster occurs, the processor designates a surviving node as the original supply node and designates a new node or a recovery target node as the target node, and automatically re-replicates and recovers the lost data from the original supply node; wherein the processor sets a retention period, a destruction schedule, and version management in units of files, buckets, or tenants according to a data lifecycle policy, and performs selective recovery by applying the lifecycle policy during disaster recovery. Effects of the invention

[0023] The present invention provides the advantage of ensuring data survivability even if a specific node or data center fails, by replicating and storing the original data on multiple geographically distributed nodes.

[0024] The present invention provides the advantage of uninterrupted recovery without administrator intervention by providing a self-healing recovery function that automatically re-replicates original data fragments from surviving nodes in the event of a disaster.

[0025] The present invention provides advanced security suitable for enterprise environments through integrity verification using CID and trust anchors, and multi-layered access control based on Bearer Tokens, Swarm Keys, and TLS.

[0026] The present invention has the advantage of providing policy-based data management functions equivalent to enterprise storage, such as replication factor maintenance, version control, lifecycle policy-based selective recovery, and tenant policy isolation.

[0027] The present invention has the advantage of dramatically improving upload and query performance by operating a cluster based on high-performance servers and low-latency networks, and providing services without performance degradation even during disaster recovery. Brief explanation of the drawing

[0028] FIG. 1 is a network configuration diagram of an IPFS-based data storage device according to an embodiment of the present invention. Figure 2 is a detailed configuration diagram of the processor shown in Figure 1. FIG. 3 is a flowchart illustrating an IPFS-based data storage method according to an embodiment of the present invention. Figure 4 is a detailed flowchart of S710 of Figure 3. Figure 5 is a detailed flowchart of S720 of Figure 3. Figure 6 is a detailed flowchart of S730 of Figure 3. Specific details for implementing the invention

[0029] Various embodiments of the present disclosure are described below in conjunction with the accompanying drawings. As various embodiments of the present disclosure may be subject to various modifications and may have various forms, specific embodiments are illustrated in the drawings and described in detail. However, this is not intended to limit the various embodiments of the present disclosure to specific forms, and it should be understood that they include all modifications and / or equivalents and substitutions that fall within the spirit and scope of the various embodiments of the present disclosure. Similar reference numerals have been used for similar components in connection with the description of the drawings.

[0030] In the various embodiments of the present disclosure, terms such as “comprising” or “having” are intended to specify the existence of the features, numbers, steps, actions, components, parts, or combinations thereof described in the specification, and should be understood as not precluding the existence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof.

[0031] In various embodiments of the present disclosure, expressions such as “or” include any and all combinations of the words listed together. For example, “A or B” may include A, may include B, or may include both A and B. Expressions such as “first,” “second,” “first,” or “second” used in various embodiments of the present disclosure may modify various components of the various embodiments but do not limit such components. For example, such expressions do not limit the order and / or importance of such components and may be used to distinguish one component from another. When a component is referred to as being “connected” or “joined” to another component, it should be understood that the component may be directly connected to or joined to the other component, or that a new component may exist between the component and the other component. In embodiments of the present disclosure, terms such as “module,” “unit,” “part,” etc. are used to refer to a component that performs at least one function or operation, and such a component may be implemented in hardware or software, or a combination of hardware and software. In addition, multiple "modules," "units," "parts," etc., can be integrated into at least one module or chip and implemented as at least one processor, except where each needs to be implemented as individual specific hardware.

[0032] Terms such as those defined in commonly used dictionaries should be interpreted as having meanings consistent with their meanings in the context of the relevant technology and should not be interpreted in an ideal or overly formal sense unless explicitly defined in the various embodiments of the present disclosure.

[0033] Hereinafter, an IPFS-based data storage device and method according to an embodiment of the present invention will be described in more detail based on the attached drawings.

[0034] FIG. 1 is a configuration diagram of an IPFS-based data storage device according to an embodiment of the present invention.

[0035] As illustrated in FIG. 1, an IPFS-based data storage device (100) according to an embodiment of the present invention includes a communication unit (110), a memory (120), and a processor (130).

[0036] The communication unit (110) is configured as a network interface for transmitting and receiving data and control signals bidirectionally with multiple IPFS nodes included in a private IPFS network, and operates to periodically or asynchronously exchange messages such as status information, replication commands, data block transmission, policy change notifications, and disaster detection events between nodes. For example, when the communication unit (110) transmits a replica of a specific block to another node according to the instructions of the replication management unit (131), it may apply a parallel transmission method to minimize network delay, and during this process, it continuously checks the connection status between nodes to ensure stability.

[0037] The communication unit (110) includes node identification management functions and session management functions suitable for the peer-to-peer structure of IPFS, and each node is mutually authenticated through a unique node identifier and a public key-based addressing scheme. At this time, the communication unit (110) ensures the confidentiality and integrity of data transmission between nodes by using a TLS-based encryption channel or the IPFS's own encryption layer. In addition, the communication unit (110) transmits replication, deletion, and redeployment commands to each node in conjunction with the replication management unit (131), disaster detection unit (132), self-healing recovery unit (133), and policy-based modules of the processor (130), and reports status information such as available capacity, storage block list, connection status, and resource utilization collected from each node as metadata in the memory (120), thereby enabling monitoring of the overall system status. The communication unit (110) applies an event-based asynchronous messaging method during data transmission to support parallel block exchange between nodes, and notifies the disaster detection unit (132) and the self-healing recovery unit (133) of the event in real time when an event such as node addition, deletion, or fault detection occurs. In addition, if packet loss or delay occurs during transmission, it performs an automatic retransmission or alternative path search function to maintain the stability of the replication and recovery procedure.

[0038] Furthermore, the communication unit (110) is configured to logically separate the data channel and the control channel so that the replication block transmission and management commands do not interfere with each other, and the control message is transmitted based on priority so that the disaster detection and recovery procedure is not delayed.

[0039] In short, the communication unit (110) is configured to support stable and efficient overall system control, such as data replication, deletion, redeployment, disaster recovery, and status reporting, by integrally managing the exchange of data and control signals between multiple IPFS nodes along with encryption, authentication, fault response, and QoS-based transmission control functions.

[0040] Next, the memory (120) is a central management storage configuration that stores and updates instructions, program code, and metadata for each node to perform control operations of the IPFS-based data storage device (100) of the present invention, and provides reference information for operations performed by the replication management unit (131), disaster detection unit (132), self-healing recovery unit (133), integrity verification unit (134), encryption processing unit (135), access control unit (136), audit log management unit (137), lifecycle policy unit (138), tenant policy isolation unit (139), and performance optimization unit (140) of the processor (130). For example, when the replication policy of a specific tenant is changed, the memory (120) can detect a conflict by comparing it with the previous version and perform a safe update based on this.

[0041] The memory (120) can be logically divided into a permanent storage area and a high-speed access buffer, and the permanent storage area stores policies and metadata necessary for system operation, such as node registration information, node status information, CID of each data block, replica storage location, regional distribution policy, replication policy, encryption policy, and tenant-specific retention and destruction policy.

[0042] The high-speed access buffer supports rapid decision-making by storing replication status tables, lost block lists, event queues, disaster detection records, etc., which are referenced in real time by the replication management unit (131) and the self-healing recovery unit (133), in a cache format.

[0043] Additionally, the memory (120) maintains a data distribution table containing the CID, replica location, replication factor, access frequency, and last modified time of each data object, which is used as reference data by the replication management unit (131) to evaluate the replication status and determine whether to relocate. When a policy change occurs, the memory (120) verifies policy consistency by comparing the policy table based on versions and prevents policy conflicts during the replication and recovery process by applying the policy using a transaction-based atomic update method. It also temporarily stores logs for major system events (replication execution, deletion completion, failure detection, etc.) and periodically synchronizes with the audit log management unit (137) to ensure the possibility of auditing the entire system. Furthermore, the memory (120) stores cluster status snapshots to provide reference information that can be referenced during disaster recovery or system rebalancing, and adds hash-based integrity verification information to each policy and metadata record to prevent tampering with memory data.

[0044] In short, the memory (120) is not a simple data storage, but a central management storage that integrates and manages and verifies data distribution, policy information, node status, and lifecycle metadata, and is a core component that supports the stable execution of all control and recovery operations of the processor (130).

[0045] Next, the processor (130) can perform technical functions according to an embodiment of the present disclosure to be described below by executing at least one instruction stored in memory (120). The processor (130) includes a central processing unit for a general-purpose server or a processor providing equivalent computational performance, and performs data storage, replication, disaster detection, and automatic recovery functions in a private IPFS network.

[0046] The processor (130) may include a configuration that stores data sources distributed across multiple nodes according to a data replication policy on a private IPFS network, detects a disaster when a disaster occurs in at least one of the nodes, and automatically re-replicates and recovers lost data based on fragments of data sources stored in the surviving nodes. In another embodiment, the processor (130) may configure a Pin orchestrator as a dedicated orchestration module linked with a disaster detection unit (132) to monitor the replication status between multiple geographically separated data centers in an integrated manner, and control uninterrupted recovery without service interruption based on pre-replicated original data in the event of a disaster.

[0047] In addition, in one embodiment of the present invention, the processor (130) can control the selective retrieval and recovery of only data corresponding to a specific file or a specific CID range among data distributed and stored in multiple nodes through a dedicated gateway module (not shown) linked to a CID-based address system. For example, in the case of a large file, the processor (130) can reduce the total recovery time by dividing the file into multiple blocks and then proceeding with recovery while considering the priority of each block.

[0048] More specifically, the processor (130) includes a replication management unit (131), a disaster detection unit (132), a self-healing recovery unit (133), an integrity verification unit (134), an encryption processing unit (135), an access control unit (136), an audit log management unit (137), a lifecycle policy unit (138), a tenant policy isolation unit (139), and a performance optimization unit (140).

[0049] The replication management unit (131) refers to the data replication policy (replication factor, regional distribution rule, node priority, storage capacity constraint, etc.) stored in memory (120) to subdivide the original data input via the upload request into blocks suitable for the IPFS standard, and then encrypts the blocks in a manner according to the tenant-specific policy by linking with the encryption processing unit (135). Afterward, the blocks are distributed to multiple nodes or geographically separated data centers according to the replication factor (RF). If the actual number of replicas is less than or greater than the replication factor, additional replication or deletion of unnecessary replicas is performed automatically to maintain replication consistency. Furthermore, a CID-node index table is created and managed to map the CID for each block to the node identifier where the corresponding CID is stored. Additionally, policy-based redistribution can be performed by considering load balancing and storage capacity balancing between nodes. For example, when the replication management unit (131) sets the replication factor of a specific data to 3, if the actual replica is reduced to 2, it immediately performs additional replication on the surviving node to maintain the factor, and in this process checks the available capacity of the node to prevent overload.

[0050] The disaster detection unit (132) may be configured to directly collect failure events such as API response delay, no response, handshake failure, storage volume unmount, file system error, network routing loss, link disconnection between data centers, disk read / write failure, and unexpected data deletion for all nodes within the private IPFS network, or, in one embodiment, receive the event information from an external node monitoring module such as a PIN orchestrator and perform multi-event correlation analysis based thereon to precisely determine whether a node failure or a data center-wide disaster has occurred. For example, if API response delays occur simultaneously in multiple nodes, the disaster detection unit (132) determines that it is a data center-wide disaster and immediately notifies the self-healing recovery unit (133) of this to initiate a recovery process.

[0051] When a disaster is detected by the disaster detection unit (132), the self-healing recovery unit (133) detects damaged or lost blocks by referring to the CID-node index table and generates a list of lost blocks. Then, among the original blocks corresponding to the lost blocks, blocks with maintained integrity are prioritized for re-querying and secured from the surviving nodes. After automatically selecting a target node for re-replication by considering the node's available capacity, load status, local distribution rules, and tenant policy, the replication factor is restored by replicating and storing the original blocks in their encrypted state on the selected node. Subsequently, the integrity is verified by calculating the CID of the re-replicated block and comparing it with the original CID. If the CID is inconsistent, the recovery operation is performed by retrying the replication using another surviving node or repeating the retransmission to the same node until a normal CID is secured. Finally, the CID-node index table is updated to the latest state by reflecting the storage location information of the recovered block. For example, the self-healing recovery unit (133) maintains regional diversity of data by preferentially selecting a surviving node from another data center to perform replication in the event of a disaster in a geographically separated data center.

[0052] The integrity verification unit (134) periodically scans the Content Identifier (CID) for all blocks to determine whether the stored or recovered data source has been tampered with based on the CID, and compares the scanned CID with the reference CID stored in the trusted anchor to detect abnormal signs such as ransomware attacks, unauthorized modifications, and storage tampering in real time. If tampering is confirmed, it immediately transmits a recovery request to the self-healing recovery unit (133), thereby maintaining data integrity at all times. For example, if a discrepancy occurs in the CID comparison after recovery, the integrity verification unit (134) isolates the block and searches for an alternative replica to ensure stability.

[0053] The encryption processing unit (135) manages data encryption keys according to encryption policies set per tenant or per service before storing the data source as an IPFS block, performs real-time encryption on a block-by-block basis by applying an encryption algorithm specified in the policy, and during the disaster recovery process, retransmits and redistributes the blocks in their encrypted state, but verifies their validity through decryption if necessary, thereby continuously ensuring the confidentiality and security of the stored data. For example, the encryption processing unit (135) encrypts the blocks using the AES-256 algorithm and enhances the security level by applying a key rotation policy during key management.

[0054] The access control unit (136) can prevent unauthorized users from accessing data by applying Bearer Token-based user authentication, Swarm Key-based network isolation, TLS-based transport layer encryption, and tenant-specific role-based access control in an integrated manner to perform multi-layered security control on data access over a private IPFS network, and by immediately blocking or warning when abnormal access attempts or unauthorized requests are detected. For example, the access control unit (136) prevents external intrusion by isolating the network with a Swarm Key after verifying the validity of the Bearer Token.

[0055] The audit log management unit (137) can store all key events occurring in the system, such as data access history, user request history, disaster detection and recovery processing records, in a time-series based database (not shown) such as TimescaleDB, and can record user identification information, access time, type of API called, access target CID, whether recovery was performed, whether policy was violated, and the cause of disaster and response procedure as standardized log items, and can continuously manage the log data so that it can be used for security audits, failure analysis, or legal evidence.

[0056] In particular, the audit log management unit (137) can provide traceability and auditing capabilities for the entire disaster recovery process by recording in detail in TimescaleDB the history of data access requests and recovery command executions that occur during the disaster recovery procedure at each recovery stage. For example, the audit log management unit (137) stores the history of access to each block along with timestamps during recovery, so that the cause of the disaster can be analyzed during a subsequent audit.

[0057] The lifecycle policy unit (138) defines the importance and recovery priority at the file, bucket, and tenant levels as policies, and may be configured to minimize the recovery time (RTO) by performing recovery sequentially starting with files of high priority during disaster recovery. For example, the lifecycle policy unit (138) is configured to automatically destroy files whose retention period has expired, and selectively recovers only the latest versions through version control during recovery.

[0058] The tenant policy isolation unit (139) independently maintains and manages replication policies, encryption policies, geographic distribution policies, and data lifecycle policies set for each tenant in a multi-tenant environment so that they do not interfere with each other, and ensures that policies for each tenant are applied individually even during disaster recovery, thereby preventing policy conflicts between tenants and guaranteeing service independence and data isolation levels. For example, the tenant policy isolation unit (139) applies a virtual isolation layer so that a change in one tenant's replication policy does not affect other tenants.

[0059] The performance optimization unit (140) can maintain overall service quality stably by applying performance enhancement techniques such as routing control based on the load status of nodes, caching policy adjustment, network latency analysis, and parallel upload and download processing to optimize data upload and query performance in a private IPFS cluster environment composed of high-performance servers and low-latency networks, and by dynamically adjusting cluster resources so that the system's response delay does not increase or processing performance degrades even while the disaster recovery procedure is being performed. For example, the performance optimization unit (140) can avoid nodes with high load during recovery and improve upload speed by more than double through parallel processing.

[0060] Meanwhile, multiple IPFS nodes are independent storage and transmission units participating in a private IPFS network, and are storage nodes in which data sources are divided into blocks and then distributed and stored according to the replication policy of the replication management unit (131). Each node includes its own storage volume and IPFS daemon, and can identify whether a specific block is stored according to a CID-based addressing method. Furthermore, in conjunction with the disaster detection unit (132) and the self-healing recovery unit (133), the configuration enables automatic recovery of lost blocks by providing blocks stored in surviving nodes in the event of a failure such as a node status abnormality, storage damage, or disconnection.

[0061] Each IPFS node stores encrypted block data in its own local storage and maintains the addressability of the block through the CID generated when storing the block, and an abnormal state may be reported by the disaster detection unit (132) when a storage failure (file deletion, disk error, unmount) occurs.

[0062] Each IPFS node communicates with other nodes and processors (130) through a TLS-based secure channel and maintains security by configuring a dedicated private network separated from the external IPFS network through a Swarm Key.

[0063] When each node receives a CID request, it checks whether the corresponding block exists locally; if it does, it returns it in its encrypted state, and if it does not exist, the query request is forwarded to an adjacent node or a node designated by the processor according to routing rules.

[0064] In the event of a disaster, the surviving node acts as a 'Source Node' that provides the recovery target block at the request of the self-healing recovery unit (133), and the new node or recovery target node acts as a 'Target Node' that accepts the replica.

[0065] Nodes can be selected by the replication management unit (131) as target nodes for replication and deployment based on various factors such as replication factor, regional distribution policy, remaining storage capacity, and load status. For example, IPFS nodes are deployed to the Seoul Data Center and the Busan Data Center respectively according to the regional distribution policy during replication to increase survivability in the event of a disaster.

[0066] FIG. 3 is a flowchart illustrating an IPFS-based data storage method according to an embodiment of the present invention, FIG. 4 is a detailed flowchart of S710 of FIG. 3, FIG. 5 is a detailed flowchart of S720 of FIG. 3, and FIG. 6 is a detailed flowchart of S730 of FIG. 3.

[0067] First, referring to FIG. 3, an IPFS-based data storage method (S700) according to an embodiment of the present invention first stores a data source by distributing it across a plurality of nodes according to a data replication policy on a private IPFS network (S710), and then detects the disaster when it occurs at least one of the nodes (S720). Subsequently, it includes a series of processes to automatically re-replicate and recover the lost data based on the fragment of the data source stored on the surviving node (S730).

[0068] Referring to FIG. 4, step S710 is a process for securely replicating and storing an input data source to multiple nodes according to an IPFS-based distributed storage policy, and may include steps S711 to S715.

[0069] Step S711 is a stage where the processor receives an upload request and loads the data source included in the request into an internal processing buffer. During this step, the size, format, tenant information, and encryption policy of the data source are verified, and preparation work for block splitting and encryption is subsequently performed. For example, if the upload request involves a large file, the file is divided into chunks in Step S711 to reduce memory load.

[0070] Step S712 is a step of dividing the received data source into multiple blocks to conform to the IPFS block standard; each block includes block size information, a block index, and metadata, and the divided blocks are subsequently used in the encryption and replication processes.

[0071] Step S713 is a step of encrypting each divided block in real time according to the tenant-specific encryption policy, wherein the encryption processing unit (135) encrypts all blocks by applying a specified encryption algorithm (such as AES) and then transmits them to the replication process while maintaining the encrypted state.

[0072] Step S714 is a step of transmitting and storing encrypted blocks in parallel to multiple selected IPFS nodes based on a replication policy (replication factor RF, regional distribution policy, etc.), wherein the replication management unit (131) autonomously determines the optimal replication target nodes by considering the node load status, network latency, data center location, etc. For example, if a regional distribution policy is applied, blocks are distributed and stored on nodes in different geographical locations in Step S714.

[0073] Step S715 is a step that maintains replica consistency by checking whether the replicas of each block match the Replication Policy (RF), performing additional replication if there is a shortage, and cleaning up unnecessary replicas if there is an excess. Additionally, Step S715 generates a Content Identifier (CID) for each block and records the node information where the block is stored in a CID-node mapping table so that it can be utilized for future disaster recovery and integrity verification.

[0074] Step S720 is a process for detecting in real time whether a node failure or a data center-level disaster has occurred within a private IPFS network, and may include steps S721 through S726.

[0075] Step S721 is a step in which the disaster detection unit periodically collects node operation status information, such as API response time, response success rate, and handshake success status from IPFS nodes, and key status values ​​are obtained to primarily determine whether the node is normal or abnormal.

[0076] Step S722 monitors the storage volume status of each node to detect abnormal events occurring at the storage level, such as file system errors, read / write failures, storage volume unmounting, and unexpected file deletion, providing a diagnostic basis for distinguishing between storage failures and overall node failures.

[0077] Step S723 analyzes the status of communication paths between nodes to detect network-level failures, such as network bottlenecks, routing losses, disconnections between data centers, and spikes in latency. It serves to verify connectivity across the entire IPFS network and the viability of links between data centers. For example, if a disconnection between data centers is detected in Step S723, it is immediately classified as a disaster.

[0078] Step S724 may be a step for cross-correlating various failure events collected in Steps S721 through S723 to determine whether the issue is a simple temporary delay, a failure of a specific node, or a disaster situation affecting the entire data center.

[0079] Step S725 is a step for finally determining whether a disaster has occurred based on the results of the correlation analysis above, and the determination result can be classified into forms such as 'normal', 'node failure', 'storage failure', 'data center-level disaster', etc.

[0080] Step S726 is a step in which, when a disaster is determined, the disaster detection unit transmits a recovery start signal to the self-healing recovery unit (133) or the recovery management module, and a control signal is propagated so that the recovery procedure S730 described later can be executed immediately.

[0081] Next, step S730 is a process of restoring a normal replication state by automatically re-replicating lost data using data source fragments stored in the surviving node based on disaster detection results, and may include steps S731 through S736.

[0082] Step S731 is a step in which the self-healing recovery unit refers to the CID-node mapping table to detect blocks whose storage locations have been lost due to a disaster and generates a list of lost blocks, and blocks to be recovered are identified in Step S731.

[0083] Step S732 is a step in which an integrity-preserved original block corresponding to the lost block is retrieved from a surviving node; the retrieved block is maintained in its encrypted state and used for re-replication. For example, if there are multiple surviving nodes in Step S732, the node with the lowest latency is selected first.

[0084] Step S733 is a step that automatically selects recovery target nodes by considering the node's available capacity, load status, regional distribution policy, and tenant policy to determine where to re-replicate blocks that have lost replicas due to a disaster.

[0085] Step S734 is a step in which the original block obtained from the surviving node is replicated and stored on the recovery target node in its encrypted state, and security consistency is guaranteed so that the encryption state of the existing block is maintained without change during this process.

[0086] Step S735 verifies integrity by recalculating the CID of the recovered block and comparing it with the original CID, and if the CIDs do not match, it retryes replication using another surviving node or repeats retransmission to the same node.

[0087] Step S736 is a step that updates block-specific storage information to the latest state by reflecting the new storage locations of recovered blocks in the CID-node mapping table, and the updated table is referenced during subsequent disaster detection and additional recovery processes.

[0088] Accordingly, according to the IPFS-based data storage device and method of the embodiment of the present invention, by replicating and storing a data source on a plurality of geographically distributed nodes, the advantage of ensuring data survivability even if a failure occurs in a specific node or data center is provided.

[0089] In addition, the present invention provides the advantage of uninterrupted recovery without administrator intervention by providing a self-healing recovery function that automatically re-replicates original data fragments from surviving nodes in the event of a disaster.

[0090] In addition, the present invention provides advanced security suitable for enterprise environments through integrity verification using CID and trust anchors, and multi-layered access control based on Bearer Tokens, Swarm Keys, and TLS.

[0091] In addition, the present invention has the advantage of providing policy-based data management functions equivalent to enterprise storage, such as replication factor maintenance, version control, lifecycle policy-based selective recovery, and tenant policy isolation.

[0092] In addition, the present invention has the advantage of dramatically improving upload and query performance by operating a cluster based on high-performance servers and low-latency networks, and providing services without performance degradation even during disaster recovery.

[0093] Meanwhile, the methods according to the various embodiments of the present invention described above may be implemented in the form of an application or software program that can be installed on an existing electronic device. In addition, all or part of the method may be composed of multiple software function modules and implemented on an operating system (OS). Alternatively, each step may be composed of a single software function module, or each step may be combined to form a single software function module and implemented on an operating system. Therefore, even if all of the embodiments of the present disclosure are not implemented as a single software function module, if multiple software function modules implement each step of the present disclosure and multiple software function modules are implemented on a single operating system, it can be understood that the method of the present disclosure has been implemented.

[0094] In addition, the methods according to the various embodiments of the present invention described above can be implemented solely through software upgrades or hardware upgrades of existing electronic devices. Furthermore, the various embodiments of the present invention described above can also be performed through an embedded server equipped in an electronic device or an external server of the electronic device.

[0095] Meanwhile, according to one embodiment of the present invention, the various embodiments described above may be implemented as software comprising instructions stored on a computer-readable recording medium using software, hardware, or a combination thereof. In some cases, the embodiments described herein may be implemented as the processor itself. According to the software implementation, embodiments such as the procedures and functions described herein may be implemented as separate software modules. Each of the software modules may perform one or more functions and operations described herein. Meanwhile, a computer or similar device may include a device according to the disclosed embodiments, which is capable of calling instructions stored from a storage medium and operating according to the called instructions. When said instructions are executed by a processor, the processor may perform the function corresponding to said instructions directly or using other components under the control of said processor. The instructions may include code generated or executed by a compiler or an interpreter. A machine-readable recording medium may be provided in the form of a non-transitory computer-readable recording medium. Here, "non-transitory" simply means that the storage medium does not contain a signal and is tangible; it does not distinguish whether data is stored semi-permanently or temporarily on the storage medium. In this context, a non-transitory computer-readable medium refers to a medium that stores data semi-permanently and is readable by a machine, rather than a medium that stores data for a brief moment, such as registers, caches, or memory.Specific examples of non-transient computer-readable media include CDs, DVDs, hard disks, Blu-ray discs, USBs, memory cards, ROMs, etc.

[0096] As described above, exemplary embodiments have been disclosed in the drawings and specification. Although specific terms have been used to describe the embodiments in this specification, they are used only for the purpose of explaining the technical concept of this disclosure and are not intended to limit the meaning or the scope of this disclosure as defined in the claims. Therefore, those skilled in the art will understand that various modifications and equivalent alternative embodiments are possible therefrom. Accordingly, the true technical scope of protection of this disclosure should be determined by the technical concept of the appended claims. Explanation of the symbols

[0097] 100: IPFS-based data storage device 110: Communications Department 120: Memory 130: Processor 131: Replication Management Department 132: Disaster detection unit 133: Self-healing restoration section 134: Integrity Verification Department 135: Encryption processing unit 136: Access control unit 137: Audit Log Management Department 138: Life Cycle Policy Department 139: Tenant Policy Isolation 140: Performance Optimization Section

Claims

Claim 1 An IPFS-based data storage device comprising: a communication unit; a memory storing at least one command and data replication policy information; and a processor that performs operations according to the command, wherein the processor selects a replication target node and a deployment target node by considering a replication factor, a local distribution policy, the remaining storage capacity of the node, and a load state on a private IPFS network, stores a data source by distributing and replicating it to a plurality of nodes according to the data replication policy information, detects the disaster when a disaster occurs at least one of the nodes, designates a surviving node as the original supply node and designates a new node or a recovery target node as the target node, recovers the lost data blocks by re-receiving them from the original supply node and automatically re-replicating them, sets a retention period, a destruction schedule, and version management on a file, bucket, or tenant basis according to the data lifecycle policy, and performs selective recovery by applying the lifecycle policy during disaster recovery. Claim 2 An IPFS-based data storage device according to claim 1, wherein the processor sets a replication factor (RF) of a data source based on the data replication policy, automatically performs additional replication when the actual number of replicas is less than the replication factor, and removes unnecessary replicas when it exceeds the number to maintain consistency. Claim 3 An IPFS-based data storage device according to claim 1, wherein the processor encrypts and stores the data source, re-replicates the encrypted data source fragment from a surviving node during disaster recovery, and can verify integrity after recovery by comparing a Content Identifier (CID) with a trusted anchor to check for tampering. Claim 4 In claim 1, the processor is an IPFS-based data storage device capable of monitoring node failures in real time through a PIN orchestrator upon detection of the disaster and replicating data sources between geographically separated data centers to perform uninterrupted recovery in the event of a disaster. Claim 5 delete Claim 6 In claim 1, the processor is an IPFS-based data storage device capable of applying a multi-layer access control technique to allow only authorized users to access data via Bearer Token, Swarm Key, and TLS, and providing an auditing function by recording access logs in TimescaleDB during the disaster recovery process. Claim 7 In claim 1, the processor is an IPFS-based data storage device capable of supporting file-unit priority recovery during disaster recovery to minimize recovery time to time (RTO), and performing selective recovery through CID-based addressing and a dedicated gateway. Claim 8 In claim 1, the processor is an IPFS-based data storage device that applies policy isolation on a tenant basis to independently set replication, encryption, lifecycle, and geolocation policies, and maintains tenant-specific isolated policies during disaster recovery. Claim 9 In claim 1, the processor is an IPFS-based data storage device capable of optimizing data upload and query performance through a cluster composed of a high-performance server and a low-latency network, and performing automatic recovery without performance degradation during disaster recovery. Claim 10 An IPFS-based data storage method comprising: a step in which a processor selects a replication target node and a deployment target node by considering a replication factor, a regional distribution policy, the remaining storage capacity of the node, and a load status on a private IPFS network, and stores a data source by distributing and replicating it to a plurality of nodes according to data replication policy information; a step in which the processor detects a disaster when a disaster occurs at least one of the plurality of nodes; and a step in which, when a disaster occurs, the processor designates a surviving node as the original supply node and designates a new node or a recovery target node as the target node, and automatically re-replicates and recovers the lost data from the original supply node; wherein the processor sets a retention period, a destruction schedule, and version management on a file, bucket, or tenant basis according to a data lifecycle policy, and performs selective recovery by applying the lifecycle policy upon disaster recovery.

Images