WO2015067892A1 - Procédé de protection de métadonnées - Google Patents

Procédé de protection de métadonnées Download PDF

Info

Publication number
WO2015067892A1
WO2015067892A1 PCT/FR2014/052818 FR2014052818W WO2015067892A1 WO 2015067892 A1 WO2015067892 A1 WO 2015067892A1 FR 2014052818 W FR2014052818 W FR 2014052818W WO 2015067892 A1 WO2015067892 A1 WO 2015067892A1
Authority
WO
WIPO (PCT)
Prior art keywords
metadata
server
client
file
data
Prior art date
Application number
PCT/FR2014/052818
Other languages
English (en)
Inventor
Liana BOZGA
Sébastien BUISSON
Jean-Olivier GERPHAGNON
Original Assignee
Bull Sas
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bull Sas filed Critical Bull Sas
Publication of WO2015067892A1 publication Critical patent/WO2015067892A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2038—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with a single idle spare processing component
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2048—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share neither address space nor persistent storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/16—File or folder operations, e.g. details of user interfaces specifically adapted to file systems
    • G06F16/164—File meta data generation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection

Definitions

  • the technical field of the invention is that of methods for protecting metadata.
  • the data is globally divided into two subsets:
  • Metadata which define a certain number of characteristics relating to the data of the file, such as for example:
  • o rights - that is, who can read, write, edit the file, o and, at a finer level, where the file is physically located on a storage medium, such as a hard drive or server.
  • Metadata is also referred to as "metadata" in this document.
  • a first really plausible solution is to take a reference, that is to say perform a mathematical operation of "sum” type to identify a content in a non-repudiable manner.
  • Cryptographic hashing algorithms such as MD5 ("Message Digest 5") or SHA ("Secure Hash Algorithm") make it possible to calculate at a time T0, from an initial data input, an amount for quickly identifying the data. initial. We can thus typically check, at a time T1> T0, if the sum is always similar and therefore if the data is still intact.
  • a second solution, complementary to the first, is the regular backup of data on different media for archiving. These two solution elements remain valid for metadata.
  • a set of servers is responsible for providing access to "data”: the I / O servers.
  • a set of other servers is responsible for providing "metadata" type information: the metadata servers.
  • Physical corruption such as a failed disk
  • RAID-type mechanisms or more generally through physical redundancy.
  • a redundancy system will simply "copy” the invalid value, carrying bad information.
  • These systems are therefore particularly useless in the face of an attack on metadata.
  • metadata - just like data in general - is also susceptible to silent (“silent data corruption") corruption, which is undetected corruption.
  • Such corruption may for example be related to an error during a write process on a disk of storage.
  • the metadata information of a file is corrupted, for example if the size or physical location information of said file is erroneous, access to said file may be irretrievably lost. Indeed, without metadata, it is impossible for clients of a distributed file system to access the data itself.
  • Figures 1a to 1d illustrate a method 100 of access to a file system distributed according to the prior art.
  • the distributed file system comprises in the example shown in FIGS. 1 a to 1 d:
  • the client device C being able to communicate with the metadata server S_MD and the first and second data servers S_D1 and S_D2 through an NWK network.
  • FIGS. 1a to 1d also show a file f of the distributed file system, the file f comprising:
  • FIG. 1a shows a step, in the method 100, of obtaining the MD_f metadata of the file f by the client C.
  • a user realizes for example an instruction of type:
  • the client C sends a first message 1 to the S_MD metadata server via the network NWK in order to obtain the metadata MD_f of the file f, which notably include the storage location of the data of the file f .
  • the metadata server S_MD sends a second message 2 to the client C with the metadata MD_f of the file f whose storage location of the data of the file f.
  • the storage location of the data of the file f is as follows: the first part Df_1 of the data is stored on the first storage array B_D1 of the first data server S_D1, and the second part Df_2 of the data is stored on the second storage array B_D2 of the second data server S_D2.
  • FIG. 1b shows a step in the method 100 of accessing the data of the file f.
  • Client C sends, after receiving the second message 2:
  • a third message 3 to the first data server S_D1 via the network NWK for access to the first part Df_1 of the data.
  • the first data server S_D1 will then look for the first portion Df_1 of the data on the first storage array B_D1 and transmit said first portion Df_1 of the data to the client C;
  • a fourth message 4 to the second data server S_D2 for access to the second part Df_2 of the data.
  • the second data server S_D2 will then look for the second part Df_2 of the data on the second storage bay B_D2 and transmit said second part Df_2 of the data to the client C.
  • the data and the metadata of the file f are now on the client C, which can actually access the data of the file f and perform operations that modify the file f. These operations can modify:
  • FIG. 1c shows a step in the method 100 of modifying the file f by the user of the client C and of updating the data of the file f.
  • the client C thus accesses the file f, reads the file f, writes to the file f and therefore adds additional data to the file f, closes the file f and changes the rights of the file f.
  • the client C then sends a fifth message 5 to the S_MD metadata server via the network NWK in order to know where to add the third part Df_3 of the data of the file f: the client C requests a space allocation to the metadata server S_MD.
  • the S_MD metadata server responds with a sixth message 6 to the client C via the server NWK and indicates, for example, the client C to add the third part Df_3 of the data of the file f to a third data server S_D3.
  • the third data server S_D3 is associated with a third storage bay B_D3.
  • the client C then sends a seventh message 7 to the third data server S_D3 via the network NWK for writing the third part Df_3 of the data of the file f on the third storage bay B_D3.
  • FIG. 1 d shows a step in the method 100 of updating the metadata MD_f of the file f.
  • the client C sends an eighth message 8 to the metadata server S_MD via the network NWK for the update of the metadata MD _f in order to take into account account the addition of data, the new size of the file f, the location of each part of the data, the new permissions, the modification time, the access time, etc.
  • the MD_f metadata allowing access to the data of the file f will no longer be valid and access to the file f will be invalid, that is to say that one will access for example the data of a file other than the file f, or impossible, that is to say one will not access any data.
  • the invention offers a solution to the problems mentioned above, by proposing a method of protecting metadata against silent corruption or malicious attack.
  • the invention therefore essentially relates to a method of protecting metadata, said metadata describing a file in a storage system and being recorded on a main server, the protection method being characterized in that said metadata are recorded on a secondary server and in the process comprises the following steps:
  • a client obtains an identifier of the main server
  • the client sends a request to the main server in order to obtain the metadata describing the file, the request comprising an identifier of the file;
  • the main server sends a response to the client, the response comprising the metadata describing the file;
  • the client sends a message to the main server for updating the metadata on the main server, and the client sends a message to the secondary server for the update of the metadata on the secondary server, the client having previously obtained a identifier of the secondary server.
  • the invention provides, in a storage system, a duplication on a main server and on at least one secondary server metadata of each file stored in the storage system. It is the client, not the primary server, that sends a message to the secondary server for updating the metadata on the secondary server.
  • the method of the invention thus makes it possible to overcome a possible failure or corruption of the main server or the secondary server, considering that the client is reliable.
  • the method of protection of metadata according to the invention may have one or more additional characteristics among the following, considered individually or in any technically possible combination:
  • the client obtains the identifier of the secondary server at the same time as it obtains the identifier of the main server.
  • the response sent by the main server to the client comprises:
  • the client thus obtains, in this second mode of operation, the identifier of the secondary server after having interrogated the main server.
  • the list is advantageously protected by an encryption technique, access to said list requiring a decryption key.
  • the robustness of the metadata protection device is improved by securing access to the identifier of the secondary server, for example in the case where the response sent by the main server to the client is intercepted by a malicious device.
  • the decryption key is advantageously unknown to the main server. Thus, it contributes to improving the robustness of the metadata protection device by securing access to the identifier of the secondary server in the case where the main server is corrupted.
  • the decryption key is advantageously known only to the client, the client being deemed reliable.
  • the client updates the metadata on the primary server and on the secondary server in a predefined update order.
  • the update of the file metadata by the client is advantageously validated when all the servers are updated. This maximizes the security and protection of metadata.
  • the update of the file metadata by the client is advantageously validated when at least one server is updated.
  • it improves the speed of execution of the metadata protection method from the point of view of the customer.
  • the invention also relates to a method in which the metadata are recorded on a plurality of secondary servers and comprising the following steps:
  • the client sends a request to the main server to obtain the metadata describing the file, the request comprising an identifier of the file;
  • the main server sends a response to the client, the response comprising the metadata describing the file;
  • the client issues a message to the primary server for updating the metadata on the primary server, and the client sends a message to each secondary server of the plurality of secondary servers for updating the metadata on the plurality of secondary servers , the client having previously obtained an identifier of each secondary server of the plurality of secondary servers.
  • FIG. 1a shows a step of obtaining the metadata of a file in a method of accessing a distributed file system of the prior art.
  • FIG. 1b shows a step of accessing the data of the file in the method of FIG. 1a.
  • FIG. 1c shows a step of modifying the file and updating the data of the file f in the method of FIG. 1a.
  • FIG. 1 d shows a step of updating the metadata of the file in the method of FIG. 1a.
  • FIG. 2a shows a second step of a metadata protection method according to one embodiment of the invention.
  • FIG. 2b shows a third step of the metadata protection method of FIG. 2a.
  • FIG. 2c shows a fourth step of the metadata protection method of FIG. 2a.
  • FIG. 3 is a diagram of the organization of the steps of the metadata protection method of FIG. 2a.
  • the method 200 for protecting metadata is implemented in a distributed file system infrastructure shown in FIGS. 2a to 2c and comprising the following elements:
  • a client device C that can communicate with the main metadata server S_MD1, the secondary metadata server S_MD2 and the first, second and third data servers S_D1, S_D2 and S_D3 through an NWK network.
  • FIGS. 2a to 2c also show a file f of the distributed file system, the file f comprising:
  • the metadata MD_f of the file f are thus duplicated in two different locations of the distributed file system, on the main storage array B_MD1 controlled by the main metadata server S_MD1 and on the secondary storage array B_MD2 controlled by the secondary metadata server S MD2.
  • the method 200 for protecting metadata intervenes notably during the update of the metadata MD_f of the file f, subsequent to a modification of said metadata MD_f.
  • Such a modification of the metadata MD_f of the file f typically occurs when the client C accesses the file f, for example following a user's instruction of type:
  • MyFile is the name of the file f.
  • the client C obtains, for example by means of a local configuration file or via a mechanism similar to the DHCP protocol or the use of specific options of the protocol DHCP, the address of the main metadata server S_MD1 and, in a first mode of operation, the address of the secondary server S_MD2 metadata.
  • the first step 201 is represented in FIG.
  • Figure 2a shows a second step 202 of the method 200 for protecting metadata.
  • the client C sends a first request 11 to the main metadata server S_MD1 via the network NWK in order to obtain the metadata MD_f of the file f.
  • the first request 1 1 comprises for this purpose an identifier of the file f.
  • Figure 2b shows a third step 203 of the method 200 for protecting metadata.
  • the main metadata server S_MD1 sends a response 12 to the client C via the network NWK, the response 12 comprising the metadata MD_f of the file f.
  • the client C can actually access the file f and, according to the instructions of a user of the client C, perform a plurality of operations on the file f, such as for example read the file f and / or write to the file f, then close the file f and possibly change the access rights of the file f.
  • the client C proceeds to update the data of the file f and update the metadata of the file f.
  • one or more parts Df_1 to Df_3 of the data of the file f can be modified or deleted, and new parts of the data of the file f can be added.
  • Client C requests space allocation from the main S_MD1 metadata server to find out where and how to store the updated data of the file f, that is, how to split the updated data into several parts, and to which data server to send each part.
  • a case is considered in which, at the end of updating the data of the file f, the first, second and third parts Df_1, Df_2 and Df_3 are always stored data respectively. by the first, second and third data servers S_D1, S_D2 and S_D3. This case corresponds for example to an access to the file f of type open ().
  • the client C updates the MD_f metadata f file.
  • Figure 2c shows a fourth step 204 of the method 200 for protecting metadata.
  • the client C sends a message 13 to the main metadata server S_MD1 via the network NWK for the update of the metadata MD_f on the main server S_MD1, and the client C sends a message 14 to the secondary server S_MD2 metadata for MD_f metadata update on the S_MD2 metadata secondary server.
  • the secondary S_MD2 metadata server is preferably integrated at a low level via a metadata access and modification protocol in order to reduce the risk of an attack on said secondary S_MD2 metadata server.
  • the secondary server S_MD2 metadata can take the relay, with valid information.
  • the first mode of operation in which the client C obtains the identifier of the secondary metadata server S_MD2 simultaneously with the identifier of the main metadata server S_MD1 during the first step 201, has already been described, for example in an initialization phase. of the client C.
  • the client C can only obtain the identifier of the main metadata server S_MD1 during the first step 201, and obtain the identifier of the secondary metadata server S_MD2 during the third step 203
  • the response 12 comprises, in addition to the metadata MD_f of the file f, a list comprising an identifier of the secondary server S_MD2 metadata.
  • the client C thus obtains the identifier of the secondary server S_MD2 metadata after interrogating the main server metadata S_MD1, which he knew the identifier after the first step 201.
  • the second mode of operation advantageously makes it possible for the identifier of the secondary S_MD2 metadata server to be transmitted to the client C only when the client C accesses metadata.
  • FIGS. 2a to 2c show an embodiment of the metadata protection method 200 implementing a single secondary metadata server. Nevertheless, the method 200 for protecting metadata could quite well, in a second embodiment, implement a plurality of secondary metadata servers.
  • the first and second modes of operation previously described are compatible with the second embodiment.
  • the client C can obtain the identifier of each server of the plurality of secondary metadata servers:
  • the list of the response 12 sent by the main metadata server S_MD1 to the client C at step 203 comprises then the identifier of each server of the plurality of secondary metadata servers.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Human Computer Interaction (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Storage Device Security (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un procédé de protection de métadonnées (MD_f), les métadonnées décrivant un fichier (f) dans un système de stockage et étant enregistrées sur un serveur principal (S_MD1) et sur un serveur secondaire (S_MD2), le procédé comportant les étapes suivantes: un client (C) obtient un identifiant du serveur principal (S_MD1); le client (C) émet une requête vers le serveur principal (S_MD1) afin d'obtenir les métadonnées (MD_f), la requête comprenant un identifiant du fichier (f); le serveur principal (S_MD1) émet une réponse vers le client (C), la réponse comportant les métadonnées (MD_f); le client (C) émet un message (13) vers le serveur principal (S_MD1) pour la mise à jour des métadonnées sur le serveur principal, et le client (C) émet un message (14) vers le serveur secondaire (S_MD2) pour la mise à jour des métadonnées sur le serveur secondaire, le client ayant préalablement obtenu un identifiant du serveur secondaire.

Description

PROCEDE DE PROTECTION DE METADONNEES
DOMAINE TECHNIQUE DE L'INVENTION
Le domaine technique de l'invention est celui des procédés de protection de métadonnées.
ARRIERE-PLAN TECHNOLOGIQUE DE L'INVENTION
Dans un domaine de stockage, les données sont globalement divisées en deux sous-ensembles :
- les données en tant que telles, « réelles », par exemple le contenu binaire d'un fichier comme une image ou un texte. Ces données sont également appelées « data » dans le présent document ;
- les métadonnées, qui définissent un certain nombre de caractéristiques relatives aux données « data » du fichier, comme par exemple :
o la date de création du fichier,
o la date de dernière modification du fichier,
o le nom « visuel » du fichier,
o les droits - c'est-à-dire qui peut lire, écrire, modifier le fichier, o ainsi que, à un niveau plus fin, l'endroit où le fichier se trouve physiquement sur un support de stockage, tel qu'un disque dur ou un serveur.
Les métadonnées sont également appelées « metadata » dans le présent document.
La corruption des données au sens large est un problème connu. Pour s'en prémunir, l'état de l'art propose généralement l'utilisation d'une technique RAID (de l'anglais « Redundant Array of Indépendant Disks ») qui, en répartissant les données sur plusieurs espaces de stockage, permet d'en garantir l'intégrité par rapport à un problème matériel. Cependant, ce type de technique ne couvre pas les risques de corruption, volontaire ou involontaire, liés par exemple à une attaque informatique. La modification des données et la détection de modification non désirées sont un sujet complexe.
Concernant l'aspect « data », une première solution réellement plausible est de prendre une référence, c'est-à-dire réaliser une opération mathématique de type « somme » permettant d'identifier un contenu de manière non-répudiable. Des algorithmes de hashage cryptographique comme MD5 (« Message Digest 5 ») ou SHA (« Secure Hash Algorithm ») permettent de calculer à un instant T0, à partir d'une donnée initiale fournie en entrée, une somme servant à identifier rapidement la donnée initiale. On peut ainsi typiquement vérifier, à un instant T1 >T0, si la somme est toujours similaire et donc si la donnée est toujours intègre. Une deuxième solution, complémentaire de la première, est la sauvegarde de manière régulière des données sur différents supports pour archivage. Ces deux éléments de solution restent valables pour les « metadata ». La problématique est cependant différente, surtout dans le cadre d'un système de fichiers réparti/distribué, comme on peut en trouver dans un contexte de calcul haute performance. Dans un tel environnement, un ensemble de serveurs est chargé de fournir l'accès aux « data » : les serveurs E/S. Un ensemble d'autres serveurs est chargé de fournir les informations de type « metadata » : les serveurs de métadonnées.
Une corruption physique, telle qu'un disque en panne, peut être gérée via des mécanismes de type RAID ou plus généralement via une redondance physique. Cependant, si l'information stockée, « écrite », est remplacée par une valeur invalide, un système de redondance se contentera de « recopier » la valeur invalide, porteuse d'une mauvaise information. Ces systèmes s'avèrent donc notamment inutiles face à une attaque sur des métadonnées. En l'absence d'une attaque, les métadonnées - tout comme les données d'une manière générale - sont également susceptibles de subir une corruption silencieuse (« silent data corruption »), c'est-à-dire une corruption indétectée. Une telle corruption peut par exemple être liée à une erreur lors d'un processus d'écriture sur un disque de stockage. Dans le cas où l'information de métadonnée d'un fichier est corrompue, par exemple si l'information de taille ou de localisation physique dudit fichier est erronée, l'accès audit fichier peut être irrémédiablement perdu. En effet, sans les métadonnées, il est impossible pour les clients d'un système de fichiers réparti d'accéder aux données elles-mêmes.
Les figures 1 a à 1 d illustrent un procédé 100 d'accès à un système de fichiers distribué selon l'art antérieur.
Le système de fichiers distribué comporte dans l'exemple représenté aux figures 1 a à 1 d :
- un serveur de métadonnées S_MD et une baie de stockage B_MD du serveur de métadonnées S_MD ;
- un premier serveur de données S_D1 et une première baie de stockage B_D1 du premier serveur de données S_D1 ;
- un deuxième serveur de données S_D2 et une deuxième baie de stockage B_D2 du deuxième serveur de données S_D2 ;
- un dispositif client C, le dispositif client C pouvant communiquer avec le serveur de métadonnées S_MD et les premier et deuxième serveurs de données S_D1 et S_D2 grâce à un réseau NWK.
Les figures 1 a à 1 d montrent également un fichier f du système de fichiers distribué, le fichier f comportant :
- des données, une première partie Df_1 desdites données étant stockée sur la première baie de stockage B_D1 et une deuxième partie Df_2 desdites données étant stockée sur la deuxième baie de stockage B_D2 ;
- des métadonnées MD_f stockées sur la baie de stockage B_MD du serveur de métadonnées S MD.
La figure 1 a montre une étape, dans le procédé 100, d'obtention des métadonnées MD_f du fichier f par le client C.
Un utilisateur réalise par exemple une instruction de type :
fd = open(MonFichier) ; « MonFichier » étant le nom du fichier f.
Suite à cette instruction de l'utilisateur, le client C envoie un premier message 1 au serveur de métadonnées S_MD via le réseau NWK afin d'obtenir les métadonnées MD_f du fichier f, qui comportent notamment l'emplacement de stockage des données du fichier f. Le serveur de métadonnées S_MD envoie un deuxième message 2 au client C avec les métadonnées MD_f du fichier f dont l'emplacement de stockage des données du fichier f. En l'occurrence, l'emplacement de stockage des données du fichier f est le suivant : la première partie Df_1 des données est stockée sur la première baie de stockage B_D1 du premier serveur de données S_D1 , et la deuxième partie Df_2 des données est stockée sur la deuxième baie de stockage B_D2 du deuxième serveur de données S_D2.
La figure 1 b montre une étape, dans le procédé 100, d'accès aux données du fichier f. Le client C envoie, après réception du deuxième message 2 :
- un troisième message 3 au premier serveur de données S_D1 via le réseau NWK pour l'accès à la première partie Df_1 des données. Le premier serveur de données S_D1 va alors chercher la première partie Df_1 des données sur la première baie de stockage B_D1 et transmet ladite première partie Df_1 des données au client C ;
- un quatrième message 4 au deuxième serveur de données S_D2 pour l'accès à la deuxième partie Df_2 des données. Le deuxième serveur de données S_D2 va alors chercher la deuxième partie Df_2 des données sur la deuxième baie de stockage B_D2 et transmet ladite deuxième partie Df_2 des données au client C.
Les données et les métadonnées du fichier f se trouvent désormais sur le client C, qui peut accéder effectivement aux données du fichier f et réaliser des opérations qui modifient le fichier f. Ces opérations peuvent modifier :
- uniquement les métadonnées MD_f, par exemple dans le cas d'un accès de type open(), où la date de dernier accès au fichier est mise à jour dans les métadonnées MD_f, ou - les données et les métadonnées MD_f, par exemple dans le cas d'un ajout de données.
La figure 1 c montre une étape, dans le procédé 100, de modification du fichier f par l'utilisateur du client C et de mise à jour des données du fichier f.
L'utilisateur réalise par exemple les instructions suivantes :
fd = openÇMonFichier);
readÇfd, data, size);
writeÇfd, data, size);
closeÇfd);
chmodÇMonFichier, mode);
Dans l'exemple considéré, le client C accède donc au fichier f, lit le fichier f, écrit dans le fichier f et ajoute donc des données supplémentaires dans le fichier f, ferme le fichier f et change les droits du fichier f. On se place dans le cas où l'opération d'écriture entraîne la création d'une troisième partie Df_3 des données du fichier f. Le client C envoie alors un cinquième message 5 au serveur de métadonnées S_MD via le réseau NWK afin de savoir où ajouter la troisième partie Df_3 des données du fichier f : le client C demande une allocation d'espace au serveur de métadonnées S_MD. Le serveur de métadonnées S_MD répond par un sixième message 6 au client C via le serveur NWK et indique par exemple au client C d'ajouter la troisième partie Df_3 des données du fichier f sur un troisième serveur de données S_D3. Le troisième serveur de données S_D3 est associé à une troisième baie de stockage B_D3. Le client C envoie alors un septième message 7 au troisième serveur de données S_D3 via le réseau NWK pour l'écriture de la troisième partie Df_3 des données du fichier f sur la troisième baie de stockage B_D3.
Suite à cette mise à jour des données du fichier f, le système de fichiers distribué procède à la mise à jour des métadonnées MD_f du fichier f. La figure 1 d montre une étape, dans le procédé 100, de mise à jour des métadonnées MD_f du fichier f. Le client C envoie un huitième message 8 au serveur de métadonnées S_MD via le réseau NWK pour la mise à jour des métadonnées MD _f afin de prendre en compte l'ajout de données, la nouvelle taille du fichier f, la localisation de chaque partie des données, les nouvelles permissions, l'heure de modification, l'heure d'accès, etc. Ainsi, dans le procédé 100 d'accès au système de fichiers distribué selon l'art antérieur, si le serveur de métadonnées S_MD est corrompu, les métadonnées MD_f permettant d'accéder aux données du fichier f ne seront plus valides et l'accès au fichier f sera invalide, c'est-à-dire qu'on accédera par exemple aux données d'un autre fichier que le fichier f, ou impossible, c'est-à-dire qu'on n'accédera à aucune donnée.
EXPOSE DE L'INVENTION
L'invention offre une solution aux problèmes évoqués précédemment, en proposant un procédé de protection de métadonnées contre une corruption silencieuse ou contre une attaque malveillante.
L'invention concerne donc essentiellement un procédé de protection de métadonnées, lesdites métadonnées décrivant un fichier dans un système de stockage et étant enregistrées sur un serveur principal, le procédé de protection étant caractérisé en ce que lesdites métadonnées sont enregistrées sur un serveur secondaire et en ce que le procédé comporte les étapes suivantes :
- un client obtient un identifiant du serveur principal ;
- le client émet une requête vers le serveur principal afin d'obtenir les métadonnées décrivant le fichier, la requête comprenant un identifiant du fichier ;
- le serveur principal émet une réponse vers le client, la réponse comportant les métadonnées décrivant le fichier ;
- le client émet un message vers le serveur principal pour la mise à jour des métadonnées sur le serveur principal, et le client émet un message vers le serveur secondaire pour la mise à jour des métadonnées sur le serveur secondaire, le client ayant préalablement obtenu un identifiant du serveur secondaire. Grâce à l'invention, on assure, dans un système de stockage, une duplication sur un serveur principal et sur au moins un serveur secondaire des métadonnées de chaque fichier stocké dans le système de stockage. C'est le client, et non pas le serveur principal, qui envoie un message vers le serveur secondaire pour la mise à jour des métadonnées sur le serveur secondaire. Le procédé selon l'invention permet ainsi de s'affranchir d'une éventuelle défaillance ou corruption du serveur principal ou du serveur secondaire, en considérant que le client est fiable. Outre les caractéristiques qui viennent d'être évoquées dans le paragraphe précédent, le procédé de protection de métadonnées selon l'invention peut présenter une ou plusieurs caractéristiques complémentaires parmi les suivantes, considérées individuellement ou selon toutes les combinaisons techniquement possibles :
- Dans un premier mode de fonctionnement, le client obtient l'identifiant du serveur secondaire en même temps qu'il obtient l'identifiant du serveur principal.
- Dans un deuxième mode de fonctionnement, la réponse émise par le serveur principal vers le client comporte :
• les métadonnées décrivant le fichier, et
• une liste comprenant l'identifiant du serveur secondaire.
Le client obtient donc, dans ce deuxième mode de fonctionnement, l'identifiant du serveur secondaire après avoir interrogé le serveur principal.
- Dans le deuxième mode de fonctionnement, la liste est avantageusement protégée par une technique de cryptage, l'accès à ladite liste nécessitant une clé de décryptage.
Ainsi, on améliore la robustesse du dispositif de protection de métadonnées en sécurisant l'accès à l'identifiant du serveur secondaire, par exemple dans le cas où la réponse émise par le serveur principal vers le client est interceptée par un dispositif malveillant. La clé de décryptage est avantageusement inconnue du serveur principal. Ainsi, on contribue à améliorer la robustesse du dispositif de protection de métadonnées en sécurisant l'accès à l'identifiant du serveur secondaire dans le cas où le serveur principal est corrompu. La clé de décryptage est avantageusement connue uniquement du client, le client étant réputé fiable.
Dans le premier ou dans le deuxième mode de fonctionnement, le client procède à la mise à jour des métadonnées sur le serveur principal et sur le serveur secondaire suivant un ordre de mise à jour prédéfini.
La mise à jour des métadonnées du fichier par le client est avantageusement validée lorsque tous les serveurs sont mis à jour. Ainsi, on maximise la sécurité et la protection des métadonnées.
Alternativement, la mise à jour des métadonnées du fichier par le client est avantageusement validée lorsqu'au moins un serveur est mis à jour. Ainsi, on améliore la rapidité d'exécution du procédé de protection de métadonnées du point de vue du client.
L'invention concerne également un procédé dans lequel les métadonnées sont enregistrées sur une pluralité de serveurs secondaires et comportant les étapes suivantes :
• un client obtient un identifiant du serveur principal ;
• le client émet une requête vers le serveur principal afin d'obtenir les métadonnées décrivant le fichier, la requête comprenant un identifiant du fichier ;
• le serveur principal émet une réponse vers le client, la réponse comportant les métadonnées décrivant le fichier ;
le client émet un message vers le serveur principal pour la mise à jour des métadonnées sur le serveur principal, et le client émet un message vers chaque serveur secondaire de la pluralité de serveurs secondaires pour la mise à jour des métadonnées sur la pluralité de serveurs secondaires, le client ayant préalablement obtenu un identifiant de chaque serveur secondaire de la pluralité de serveurs secondaires. L'invention et ses différentes applications seront mieux comprises à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent.
BREVE DESCRIPTION DES FIGURES
Les figures sont présentées à titre indicatif et nullement limitatif de l'invention.
- La figure 1 a montre une étape d'obtention des métadonnées d'un fichier dans un procédé d'accès à un système de fichiers distribué de l'art antérieur.
- La figure 1 b montre une étape d'accès aux données du fichier dans le procédé de la figure 1 a.
- La figure 1 c montre une étape de modification du fichier et de mise à jour des données du fichier f dans le procédé de la figure 1 a.
- La figure 1 d montre une étape de mise à jour des métadonnées du fichier dans le procédé de la figure 1 a.
- La figure 2a montre une deuxième étape d'un procédé de protection de métadonnées selon un mode de réalisation de l'invention.
- La figure 2b montre une troisième étape du procédé de protection de métadonnées de la figure 2a.
- La figure 2c montre une quatrième étape du procédé de protection de métadonnées de la figure 2a.
- La figure 3 est un diagramme de l'organisation des étapes du procédé de protection de métadonnées de la figure 2a.
DESCRIPTION DETAILLEE D'AU MOINS UN MODE DE REALISATION DE L'INVENTION
Sauf précision contraire, un même élément apparaissant sur des figures différentes présente une référence unique. Le procédé 200 de protection de métadonnées est mis en œuvre dans une infrastructure de système de fichiers distribué représentée aux figures 2a à 2c et comportant les éléments suivants :
- un serveur principal de métadonnées S_MD1 et une baie de stockage principale B_MD1 du serveur principal de métadonnées S_MD1 ;
- un serveur secondaire de métadonnées S_MD2 et une baie de stockage secondaire B_MD2 du serveur secondaire de métadonnées S_MD2 ;
- un premier serveur de données S_D1 et une première baie de stockage B_D1 du premier serveur de données S_D1 ;
- un deuxième serveur de données S_D2 et une deuxième baie de stockage B_D2 du deuxième serveur de données S_D2 ;
- un troisième serveur de données S_D3 et une troisième baie de stockage B_D3 du troisième serveur de données S_D3 ;
- un dispositif client C pouvant communiquer avec le serveur principal de métadonnées S_MD1 , le serveur secondaire de métadonnées S_MD2 et les premier, deuxième et troisième serveurs de données S_D1 , S_D2 et S_D3 grâce à un réseau NWK.
Les figures 2a à 2c montrent également un fichier f du système de fichiers distribué, le fichier f comportant :
- des données, une première partie Df_1 desdites données étant stockée sur la première baie de stockage B_D1 , une deuxième partie Df_2 desdites données étant stockée sur la deuxième baie de stockage B_D2 et une troisième partie Df_3 desdites données étant stockée sur la troisième baie de stockage B_D3 ;
- des métadonnées MD_f stockées sur la baie de stockage principale B_MD1 du serveur principal de métadonnées S_MD1 et sur la baie de stockage secondaire B_MD2 du serveur secondaire de métadonnées S_MD2.
Les métadonnées MD_f du fichier f sont ainsi dupliquées en deux endroits différents du système de fichiers distribué, sur la baie de stockage principale B_MD1 contrôlée par le serveur principal de métadonnées S_MD1 et sur la baie de stockage secondaire B_MD2 contrôlée par le serveur secondaire de métadonnées S MD2. Le procédé 200 de protection de métadonnées intervient notamment lors de la mise à jour des métadonnées MD_f du fichier f, consécutive à une modification desdites métadonnées MD_f. Une telle modification des métadonnées MD_f du fichier f survient typiquement lorsque le client C accède au fichier f, par exemple suite à une instruction de l'utilisateur de type :
fd = openÇMonFichier);
« MonFichier » étant le nom du fichier f. Lors d'une première étape 201 d'initialisation du procédé 200 de protection de métadonnées, le client C obtient, par exemple grâce à un fichier de configuration locale ou via un mécanisme similaire au protocole DHCP ou l'utilisation d'options spécifiques du protocole DHCP, l'adresse du serveur principal de métadonnées S_MD1 ainsi que, dans un premier mode de fonctionnement, l'adresse du serveur secondaire de métadonnées S_MD2. La première étape 201 est représentée à la figure 3.
La figure 2a montre une deuxième étape 202 du procédé 200 de protection de métadonnées. Selon cette deuxième étape 202, le client C émet une première requête 1 1 vers le serveur principal de métadonnées S_MD1 par l'intermédiaire du réseau NWK afin d'obtenir les métadonnées MD_f du fichier f. La première requête 1 1 comprend pour ce faire un identifiant du fichier f.
La figure 2b montre une troisième étape 203 du procédé 200 de protection de métadonnées. Selon cette troisième étape 203, le serveur principal de métadonnées S_MD1 émet une réponse 12 vers le client C par l'intermédiaire du réseau NWK, la réponse 12 comportant les métadonnées MD_f du fichier f.
Une fois les métadonnées MD_f du fichier f obtenues, le client C peut effectivement accéder au fichier f et, en fonction des instructions d'un utilisateur du client C, réaliser une pluralité d'opérations sur le fichier f, comme par exemple lire le fichier f et/ou écrire dans le fichier f, puis fermer le fichier f et éventuellement changer les droits d'accès du fichier f. Lorsque le client C a terminé de réaliser cette pluralité d'opérations sur le fichier f, le client C procède à la mise à jour des données du fichier f et à la mise à jour des métadonnées du fichier f. Lors de la mise à jour des données du fichier f, une ou plusieurs parties Df_1 à Df_3 des données du fichier f peuvent être modifiées ou supprimées, et de nouvelles parties des données du fichier f peuvent être ajoutées. Le client C demande une allocation d'espace au serveur principal de métadonnées S_MD1 afin de savoir où et comment stocker les données mises à jour du fichier f, c'est-à-dire comment découper les données mises à jour en plusieurs parties, et vers quel serveur de données envoyer chaque partie. Dans l'exemple représenté à la figure 2b, on considère un cas où, à l'issue de la mise à jour des données du fichier f, on a toujours les première, deuxième et troisième parties Df_1 , Df_2 et Df_3 des données respectivement stockées par les premier, deuxième et troisième serveurs de données S_D1 , S_D2 et S_D3. Ce cas correspond par exemple à un accès au fichier f de type open(). Une fois les données du fichier f mises à jour, le client C procède à la mise à jour des métadonnées MD_f du fichier f.
La figure 2c montre une quatrième étape 204 du procédé 200 de protection de métadonnées. Selon cette quatrième étape 204, le client C émet un message 13 vers le serveur principal de métadonnées S_MD1 via le réseau NWK pour la mise à jour des métadonnées MD_f sur le serveur principal S_MD1 , et le client C émet un message 14 vers le serveur secondaire de métadonnées S_MD2 pour la mise à jour des métadonnées MD_f sur le serveur secondaire de métadonnées S_MD2. Le serveur secondaire de métadonnées S_MD2 est préférentiellement intégré à bas niveau via un protocole d'accès et de modification des métadonnées afin de diminuer le risque d'une attaque sur ledit serveur secondaire de métadonnées S_MD2. Grâce au procédé 200 de protection de métadonnées de l'invention, si le serveur principal de métadonnées S_MD1 subit une attaque et/ou une corruption de ses informations, le serveur secondaire de métadonnées S_MD2 pourra prendre le relai, avec des informations valides. On a précédemment décrit le premier mode de fonctionnement selon lequel le client C obtient l'identifiant du serveur secondaire de métadonnées S_MD2 simultanément à l'identifiant du serveur principal de métadonnées S_MD1 lors de la première étape 201 , par exemple dans une phase d'initialisation du client C. Selon un deuxième mode de fonctionnement, le client C peut obtenir uniquement l'identifiant du serveur principal de métadonnées S_MD1 lors de la première étape 201 , et obtenir l'identifiant du serveur secondaire de métadonnées S_MD2 lors de la troisième étape 203. Dans ce deuxième mode de fonctionnement, la réponse 12 comporte, outre les métadonnées MD_f du fichier f, une liste comprenant un identifiant du serveur secondaire de métadonnées S_MD2. Le client C obtient donc l'identifiant du serveur secondaire de métadonnées S_MD2 après avoir interrogé le serveur principal de métadonnées S_MD1 , dont il connaissait l'identifiant à l'issue de la première étape 201 . Le deuxième mode de fonctionnement permet avantageusement que l'identifiant du serveur secondaire de métadonnées S_MD2 ne soit transmise au client C que lorsque le client C accède à des métadonnées.
On a décrit en lien avec les figures 2a à 2c un mode de réalisation du procédé 200 de protection de métadonnées mettant en œuvre un seul serveur secondaire de métadonnées. Néanmoins, le procédé 200 de protection de métadonnées pourrait tout à fait, dans un deuxième mode de réalisation, mettre en œuvre une pluralité de serveurs secondaires de métadonnées. Les premier et deuxième modes de fonctionnement précédemment décrits sont compatibles avec le deuxième mode de réalisation. Ainsi, le client C peut obtenir l'identifiant de chaque serveur de la pluralité de serveurs secondaires de métadonnées :
- soit, dans le premier mode de fonctionnement, lors de la première étape 201 durant laquelle le client C obtient également l'identifiant du serveur principal de métadonnées S_MD1 ,
- soit, dans le deuxième mode de fonctionnement, lors de la troisième étape 203, après avoir interrogé le serveur principal de métadonnées S_MD1 à la deuxième étape 202. La liste de la réponse 12 envoyée par le serveur principal de métadonnées S_MD1 vers le client C à l'étape 203 comporte alors l'identifiant de chaque serveur de la pluralité de serveurs secondaires de métadonnées.

Claims

REVENDICATIONS
Procédé (200) de protection de métadonnées (MD_f), lesdites métadonnées (MD_f) décrivant un fichier (f) dans un système de stockage et étant enregistrées sur un serveur principal (S_MD1 ), le procédé de protection (200) étant caractérisé en ce que lesdites métadonnées (MD_f) sont enregistrées sur un serveur secondaire (S_MD2) et en ce que le procédé (200) comporte les étapes suivantes :
un client (C) obtient un identifiant du serveur principal (S_MD1 ) ;
le client (C) émet une requête (1 1 ) vers le serveur principal (S_MD1 ) afin d'obtenir les métadonnées (MD_f) décrivant le fichier (f), la requête (1 1 ) comprenant un identifiant du fichier (f) ;
le serveur principal (S_MD1 ) émet une réponse (12) vers le client (C), la réponse (12) comportant les métadonnées (MD_f) décrivant le fichier (f) ; le client (C) émet un message (13) vers le serveur principal (S_MD1 ) pour la mise à jour des métadonnées (MD_f) sur le serveur principal (S_MD1 ), et le client (C) émet un message (14) vers le serveur secondaire (S_MD2) pour la mise à jour des métadonnées (MD_f) sur le serveur secondaire (S_MD2), le client (C) ayant préalablement obtenu un identifiant du serveur secondaire (S_MD2).
2. Procédé (200) selon la revendication précédente caractérisé en ce que le client (C) obtient l'identifiant du serveur secondaire (S_MD2) en même temps qu'il obtient l'identifiant du serveur principal (S_MD1 ).
Procédé (200) selon la revendication 1 caractérisé en ce que la réponse (12) émise par le serveur principal (S_MD1 ) vers le client (C) comporte :
- les métadonnées (MD_f) décrivant le fichier (f), et
- une liste comprenant l'identifiant du serveur secondaire (S_MD2).
Procédé (200) selon la revendication précédente caractérisé en ce que la liste est protégée par une technique de cryptage, l'accès à ladite liste nécessitant une clé de décryptage.
5. Procédé (200) selon la revendication précédente caractérisé en ce que la clé de décryptage est inconnue du serveur principal.
6. Procédé (200) selon l'une quelconque des revendications précédentes caractérisé en ce que le client (C) procède à la mise à jour des métadonnées (MD_f) sur le serveur principal (S_MD1 ) et sur le serveur secondaire (S_MD2) suivant un ordre de mise à jour prédéfini.
7. Procédé (200) selon l'une quelconque des revendications précédentes caractérisé en ce que la mise à jour des métadonnées (MD_f) du fichier (f) par le client (C) est validée lorsque tous les serveurs (S_MD1 , S_MD2) sont mis à jour.
8. Procédé (200) selon l'une quelconque des revendications 1 à 6 caractérisé en ce que la mise à jour des métadonnées (MD_f) du fichier (f) par le client (C) est validée lorsqu'au moins un serveur (S_MD1 , S_MD2) est mis à jour.
9. Procédé (200) selon l'une quelconque des revendications précédentes caractérisé en ce que les métadonnées (MD_f) sont enregistrées sur une pluralité de serveurs secondaires et en ce que le procédé (200) comporte les étapes suivantes :
- un client (C) obtient un identifiant du serveur principal (S_MD1 ) ;
- le client (C) émet une requête (1 1 ) vers le serveur principal (S_MD1 ) afin d'obtenir les métadonnées (MD_f) décrivant le fichier (f), la requête (1 1 ) comprenant un identifiant du fichier (f) ;
- le serveur principal (S_MD1 ) émet une réponse (12) vers le client (C), la réponse (12) comportant les métadonnées (MD_f) décrivant le fichier (f) ;
- le client (C) émet un message (13) vers le serveur principal (S_MD1 ) pour la mise à jour des métadonnées (MD_f) sur le serveur principal (S_MD1 ), et le client (C) émet un message vers chaque serveur secondaire de la pluralité de serveurs secondaires pour la mise à jour des métadonnées (MD_f) sur la pluralité de serveurs secondaires, le client (C) ayant préalablement obtenu un identifiant de chaque serveur secondaire de la pluralité de serveurs secondaires.
PCT/FR2014/052818 2013-11-06 2014-11-05 Procédé de protection de métadonnées WO2015067892A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1360876A FR3012900B1 (fr) 2013-11-06 2013-11-06 Procede de protection de metadonnees
FR1360876 2013-11-06

Publications (1)

Publication Number Publication Date
WO2015067892A1 true WO2015067892A1 (fr) 2015-05-14

Family

ID=50478518

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2014/052818 WO2015067892A1 (fr) 2013-11-06 2014-11-05 Procédé de protection de métadonnées

Country Status (2)

Country Link
FR (1) FR3012900B1 (fr)
WO (1) WO2015067892A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112306421A (zh) * 2020-11-20 2021-02-02 昆易电子科技(上海)有限公司 一种用于存储分析测量数据格式mdf文件的方法和***

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
"Clustered Metadata Design", 15 June 2009 (2009-06-15), XP055131549, Retrieved from the Internet <URL:http://wiki.lustre.org/images/d/db/HPCS_CMD_06_15_09.pdf> [retrieved on 20140724] *
ANONYMOUS: "Clustered Metadata", 30 September 2010 (2010-09-30), XP055131550, Retrieved from the Internet <URL:http://wiki.lustre.org/index.php/Clustered_Metadata> [retrieved on 20140724] *
JUNHO JANG ET AL: "A Content-Based Load Balancing Algorithm for Metadata Servers in Cluster File Systems", 5 November 2005, PARALLEL AND DISTRIBUTED PROCESSING AND APPLICATIONS LECTURE NOTES IN COMPUTER SCIENCE;;LNCS, SPRINGER, BERLIN, DE, PAGE(S) 49 - 57, ISBN: 978-3-540-29769-7, XP019023302 *
VILOBH MESHRAM ET AL: "Can a Decentralized Metadata Service Layer Benefit Parallel Filesystems?", CLUSTER COMPUTING (CLUSTER), 2011 IEEE INTERNATIONAL CONFERENCE ON, IEEE, 26 September 2011 (2011-09-26), pages 484 - 493, XP032066066, ISBN: 978-1-4577-1355-2, DOI: 10.1109/CLUSTER.2011.85 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112306421A (zh) * 2020-11-20 2021-02-02 昆易电子科技(上海)有限公司 一种用于存储分析测量数据格式mdf文件的方法和***
CN112306421B (zh) * 2020-11-20 2021-04-30 昆易电子科技(上海)有限公司 一种用于存储分析测量数据格式mdf文件的方法和***

Also Published As

Publication number Publication date
FR3012900B1 (fr) 2015-10-30
FR3012900A1 (fr) 2015-05-08

Similar Documents

Publication Publication Date Title
US8843637B2 (en) Managed peer-to-peer content backup service system and method using dynamic content dispersal to plural storage nodes
TWI387284B (zh) 用於以積點為基礎之對等式儲存之方法、系統、及記錄相關指令的電腦儲存媒體
JP5210176B2 (ja) 複数のノードを有するストレージ・システムの保護管理方法
US10289694B1 (en) Method and system for restoring encrypted files from a virtual machine image
US11636217B2 (en) Systems and methods for breach-proof, resilient, compliant data in a multi-vendor cloud environment and automatically self heals in the event of a ransomware attack
US20190196919A1 (en) Maintaining files in a retained file system
EP1602024A1 (fr) Procede et dispositif de stockage de donnees informatiques securise
Wani et al. File system anti-forensics–types, techniques and tools
US20110314245A1 (en) Secure media system
US7953894B2 (en) Providing aggregated directory structure
US9471807B1 (en) System and method for creating a security slices with storage system resources and related operations relevant in software defined/as-a-service models, on a purpose built backup appliance (PBBA)/protection storage appliance natively
US20060282631A1 (en) Discovering data storage for backup
Ali et al. Blockstack technical whitepaper
WO2006016085A1 (fr) Procede de sauvegarde distribuee sur des postes clients dans un reseau informatique
EP4026016A1 (fr) Migration d&#39;une chaîne de blocs de données
WO2015067892A1 (fr) Procédé de protection de métadonnées
EP2300944A1 (fr) Procede et systeme de synchronisation de modules logiciels d&#39;un systeme informatique distribue en grappe de serveurs, application au stockage de donnees
US8745001B1 (en) Automated remediation of corrupted and tempered files
EP2860660A1 (fr) Système et méthode de chargement sécurisé de données dans une mémoire cache associée à un processeur sécurisé
EP2531921B1 (fr) Gestion du lieu de stockage de donnees dans un systeme de stockage distribue
EP3903210A1 (fr) Reseau de communication securisee et tracee
FR3079324A1 (fr) Procedes et systeme de gestion de donnees permettant un controle temporel des donnees
EP3036867B1 (fr) Passerelle résidentielle mettant à disposition au moins un espace mémoire privé
US20210271554A1 (en) Method and system for a cloud backup service leveraging peer-to-peer data recovery
US9064132B1 (en) Method for writing hardware encrypted backups on a per set basis

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14809463

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14809463

Country of ref document: EP

Kind code of ref document: A1