CN110825712B - Method for recovering disk cluster data managed by logical volume - Google Patents
Method for recovering disk cluster data managed by logical volume Download PDFInfo
- Publication number
- CN110825712B CN110825712B CN201911050168.2A CN201911050168A CN110825712B CN 110825712 B CN110825712 B CN 110825712B CN 201911050168 A CN201911050168 A CN 201911050168A CN 110825712 B CN110825712 B CN 110825712B
- Authority
- CN
- China
- Prior art keywords
- volume
- data
- logical volume
- current
- physical
- Prior art date
- Legal status (The legal status 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 status listed.)
- Active
Links
Classifications
-
- 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/18—File system types
- G06F16/1847—File system types specifically adapted to static storage, e.g. adapted to flash memory or SSD
-
- 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/17—Details of further file system functions
- G06F16/172—Caching, prefetching or hoarding of files
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/0671—In-line storage system
- G06F3/0673—Single storage device
- G06F3/0674—Disk device
- G06F3/0676—Magnetic disk device
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Human Computer Interaction (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention discloses a method for recovering cluster data managed by a logical volume, which is characterized by comprising the following steps: s100: loading each disk, wherein a disk cluster managed by the logic volume consists of one or more disks, and each logic volume is distributed to the one or more disks; s200: acquiring each physical volume, and acquiring UUIDs of each physical volume, offset addresses of configuration areas of each physical volume and maximum byte lengths of the configuration areas of each physical volume; s300: addressing and analyzing a configuration area managed by a logic volume of each physical volume to obtain a volume group, wherein the configuration area comprises description information of the configuration area and data of the configuration area; s400: and recovering the data according to the logical volume type managed by the logical volume, the section sequence managed by the logical volume and the section quantity.
Description
Technical Field
The invention belongs to the field of electronic data recovery and evidence obtaining, relates to a method for recovering disk cluster data, and in particular relates to a method for recovering disk cluster data managed by a logic volume.
Background
The lvm is Logical Volume Manager (logical volume management) and is a mechanism for managing disk partitions in a Linux environment, and can freely adjust the size of a file system on the premise of realizing zero shutdown in Linux, and the file system spans different disks and partitions, so that the lvm device management technology is widely used in a mass storage system.
In the prior art, the recovery and extraction of data under lvm are both based on the operating system on which the data is dependent, and if the operating system carrying the lvm is destroyed, the recovery of cluster data of the logical volume management lvm cannot be performed.
Disclosure of Invention
Aiming at the defect of the prior art, the invention provides a recovery method of cluster data which does not depend on logical volume management of an operating system where the lvm is located by analyzing configuration information in the lvm and combining a structure of cluster (Just a Bunch Of Disks ) data organization: and analyzing the data of the lvm configuration area to obtain the logical volume type managed by the logical volume, the section sequence managed by the logical volume and the section number, and recovering the data, thereby achieving the purpose of recovering the cluster data managed by the logical volume.
For ease of description, the invention may include the following terms:
pe: physical extension physical block
pv: physical volume;
pvs: physical volumes
vg: volume group
vgs: volume groups volume group
lv: logical volume
lvs: logical volumes
segment: segment(s)
JBOD: disk cluster (Just a Bunch Of Disks)
The application of the invention comprises the following steps:
s100: loading each disk, wherein a disk cluster managed by the logic volume consists of one or more disks, and each logic volume is distributed to the one or more disks;
s200: acquiring each physical volume, and acquiring UUIDs of each physical volume, offset addresses of configuration areas of each physical volume and maximum byte lengths of the configuration areas of each physical volume;
s300: addressing and analyzing a configuration area managed by a logical volume of each physical volume to obtain a volume group, wherein the configuration area comprises description information of the configuration area and data of the configuration area, and the step S300 comprises the following steps:
s301: addressing and analyzing description information of the configuration areas of each physical volume according to offset addresses of the configuration areas of each physical volume, and acquiring the offset addresses of the data of the configuration areas and byte lengths of the data of the configuration areas;
s302: addressing an offset address of the data of the configuration area, and acquiring the data of the configuration area according to the byte length of the data of the configuration area;
s303: analyzing the data of the configuration area to obtain the logical volume type, the physical block size, the physical block starting address, the section sequence and the section number of the logical volume management;
s400: and recovering the data according to the logical volume type managed by the logical volume, the section sequence managed by the logical volume and the section quantity.
Preferably, the step S200 includes the steps of:
s201: the number of addressed sectors gives an initial value of 0;
s202: judging whether the number of the addressed sectors is less than or equal to 8, if yes, executing step S203, otherwise, ending the flow;
s203: reading a currently addressed sector, and the number of addressed sectors = the number of addressed sectors +1;
s204: judging whether each value of the current sector is matched with the structure of the physical volume, if so, executing step S205, otherwise, executing step S202, wherein the metadata information represents that the current sector is raid;
s205: the UUID of the current physical volume is recorded.
Preferably, the structure of the physical volume has a data structure as shown in the following table one:
data structure of structure body of table-physical volume
Wherein, signature: the physical volume signature managed by the logical volume is fixed as a character string LABELONE, and the corresponding value is 0x454E4F4C4542414C, which is used as an identification for judging whether the current sector is the physical volume;
sector number: offset location of fabric sector of current physical volume;
checksum: checksum, CRC32 checksum from 0x14 bytes to the current identification sector end address;
type indicator: name and version information of logical volume management;
UUID: unique identification of the physical volume represented by ASCII string;
physical volume size: byte length of the logical volume, the unit is bytes;
lvm config area offset: the offset address of the logic volume management configuration area takes the initial address of the disk as the initial address, and the unit is bytes;
lvm config area size: the logical volume manages the byte length of the configuration area in bytes.
Preferably, the description information of the configuration area has a data structure as shown in the following table two:
data structure of description information of table two configuration area
Wherein, checksum: a CRC32 checksum of the configuration area, which is updated as the data of the configuration area is updated;
signature: configuring a regular character string of the area identifier: "\x20lvm2\x20x [5A% r0N ]"
version: version information
lvm config area offset: the offset address of the logic volume management configuration area takes the initial address of the disk as the initial address, and the unit is bytes;
lvm config area size: the byte length of the logical volume management configuration area is in bytes;
current lvm config offset: the offset address of the data of the current logical volume management configuration area takes the initial address of the logical volume management configuration area as the initial address, and the unit is bytes;
current lvm config size: the current logical volume manages the byte length of the configuration area in bytes.
Preferably, the step S400 includes the steps of:
s401: acquiring and judging whether the logical volume type is structed, if yes, executing step S402, otherwise, ending the flow;
s402: judging whether the current number of sections is equal to the acquired number of sections, if so, ending the flow, otherwise, executing step S403;
s403: analyzing the current section, comprising the following steps:
s4031: according to the number of the sections, the size of the current section is obtained, and the unit is a physical block;
s4032: reading information of the strips domain, acquiring a physical volume to which the current section belongs, and acquiring a disk to which the current section belongs according to the UUID;
s4033: reading information of the strips domain, acquiring an offset address of the current section in the physical volume, and calculating the offset address of the current section in the disk by adopting the following formula:
offset address of current sector in disk = offset address of current sector in physical volume × physical block size + physical block start address;
s404: and reading the data of each section according to the offset address of each section in the disk and the size of each section, and sequentially combining the data to obtain the cluster data managed by the logical volume, thereby completing the recovery of the cluster data.
The invention has the following beneficial effects: the method and the device solve the technical problem that the prior art cannot recover the cluster data managed by the logical volume after the operating system is destroyed.
Drawings
FIG. 1 is a general flow chart of the method provided by the present invention;
fig. 2 is a flowchart showing a method for obtaining a UUID, a configuration area offset address, and a maximum byte length of a configuration area according to an embodiment of the present invention.
Detailed Description
For ease of description, the invention may include the following terms:
pe: physical extension physical block
pv: physical volume;
pvs: physical volumes
vg: volume group
vgs: volume groups volume group
lv: logical volume
lvs: logical volumes
segment: segment(s)
Wherein, a plurality of pes are arranged in one pv; 1 or more pv constitute vg; more than one lv is present in vg; lv allocates space from vg; data about offset addresses and the like are stored in a small-end format except for the data formats (e.g., ASCII codes, regular strings) specifically described.
Fig. 1 shows a general flow chart of the method provided by the invention. As shown in fig. 1, the present invention includes the steps of:
s100: loading each disk, wherein a disk cluster managed by the logic volume consists of one or more disks, and each logic volume is distributed to the one or more disks;
s200: acquiring each physical volume, and acquiring UUIDs of each physical volume, offset addresses of configuration areas of each physical volume and maximum byte lengths of the configuration areas of each physical volume;
specifically, pvs are acquired, and UUID of each pvs is acquired. The disk used by lvm will first be formatted as pv, if not pv, then the disk is not the disk used by lvm. The UUID is a unique ID generated by the lvm for each pv, is an important basis for the connection of the pv and the pv, and needs to be stored after the UUID is obtained. Step S200 includes the steps of:
s201: the number of addressed sectors gives an initial value of 0;
s202: judging whether the number of the addressed sectors is less than or equal to 8, if yes, executing step S203, otherwise, ending the flow;
s203: reading a currently addressed sector, and the number of addressed sectors = the number of addressed sectors +1;
s204: judging whether each value of the current sector is matched with the structure of the physical volume, if so, executing step S205, otherwise, executing step S202, wherein the metadata information represents that the current sector is raid; the structure of the physical volume is parsed to have a data structure as shown in table one below:
data structure of structure body of table-physical volume
Wherein, signature: the physical volume signature managed by the logical volume is fixed as a character string LABELONE, and the corresponding value is 0x454E4F4C4542414C, which is used as an identification for judging whether the current sector is the physical volume;
sector number: offset location of fabric sector of current physical volume;
checksum: checksum, CRC32 checksum from 0x14 bytes to the current identification sector end address;
type indicator: name and version information of logical volume management;
UUID: unique identification of the physical volume represented by ASCII string;
physical volume size: byte length of the logical volume, the unit is bytes;
lvm config area offset: the offset address of the logic volume management configuration area takes the initial address of the disk as the initial address, and the unit is bytes;
lvm config area size: the logical volume manages the byte length of the configuration area in bytes.
S205: the UUID of the current physical volume is recorded.
S300: addressing and analyzing the configuration area managed by the logic volume of each physical volume to obtain a volume group, wherein the configuration area comprises the description information of the configuration area and the data of the configuration area, the description information of the configuration area is analyzed to have a data structure shown in the following table II,
data structure of description information of table two configuration area
Wherein, checksum: a CRC32 checksum of the configuration area, which is updated as the data of the configuration area is updated;
signature: configuring a regular character string of the area identifier: "\x20lvm2\x20x [5a% r0n ]"
version information
lvm config area offset: the offset address of the logic volume management configuration area takes the initial address of the disk as the initial address, and the unit is bytes;
lvm config area size: the byte length of the logical volume management configuration area is in bytes;
current lvm config offset: the offset address of the data of the current logical volume management configuration area takes the initial address of the logical volume management configuration area as the initial address, and the unit is bytes;
current lvm config size: the current logical volume manages the byte length of the configuration area in bytes.
Step S300 includes the steps of:
s301: according to the offset address of the configuration area of each physical volume, namely lvm config area offset, addressing and analyzing the description information of the configuration area of each physical volume, acquiring the offset address of the data of the configuration area and the byte length of the data of the configuration area, namely current lvm config offset and current lvm config size;
s302: addressing an offset address of the data of the configuration area, and acquiring the data of the configuration area according to the byte length of the data of the configuration area;
specifically, the data of the lvm configuration area is recorded and stored in ASCII characters, and the offset address (i.e., current lvm config offset) of the data of the current logical volume management configuration area is a beginning address of the logical volume management configuration area, and the byte length is current lvm config size.
The following is data of a configuration area in one embodiment of the present invention. The storage can be opened directly in text mode due to ASCII mode. Furthermore, if pv belongs to the same vg, this part of the data is identical.
S303: analyzing the data of the configuration area, and acquiring the logical volume type, the physical block size, the physical block starting address, the section sequence and the section number of the logical volume management;
specifically, in the embodiment described above, the name of the current vg is "vg0", which is composed of three pvs, that is, pv0, pv1, and pv2. The following description will take pv0 as an example:
id (8 qrhEG-8SVw-7RVr-pWkk-tdjp-E2zR-dZCK5 z) is the UUID of the vg, and the size of pe is the extension_size, which is 8192 sectors;
the starting position of pv0 is pe_start, the value is 2048 sectors, the number of the pes is pe_count, therefore, the size of pv is 511 x 8192 sectors, and id (9 fwFXD-yQpq-lroH-B29Z-Wpu2-i60F-ephug 7) is the UUID of the pv;
the vg0 contains an lv, named "lv0", of the size: (511+1) pes;
lv0 has two segments (segments) that occupy two pvs, namely pv0 and pv1, the occupancy being summarized as the following data allocation table:
data allocation table of lv0 in pv:
| pv | pe start | pe end | UUID |
| pv0 | 0 | 511 | 9fwFXd-yQpq-lroH-B29Z-Wpu2-i60F-ephug7 |
| pv1 | 0 | 1 | plAiNk-4eHP-FnwE-0Kk7-Zn31-nABx-glXrlE |
id in lv0 (i.e., fS8qE1-qi56-0Tu2-fZVL-WlZ0-pmmy-r87 kcG) is UUID of the lv;
the creation_time is the time created by the lv, the format is Unix timestamp, and the value is 1556186399, namely 2019/4/25 17:59:59;
segment_count, which is the number of segments, has a value of 2, indicating that 2 segments are included; the segment sequence is segment1 and segment2 sequence arrangement;
taking segment1 as an example for illustration:
start_extension, i.e., the starting position of the lv current section, in pe, i.e., physical block;
the size of the current section of the extension_count, i.e., lv, is in units of pe, i.e., physical block;
type is the logical volume type managed by the logical volume, the value of which is structed, and is represented as data of the just-in-a-day (JBOD) type managed by the logical volume;
the second entry value of the strips field (i.e., 0), representing the location in pv of the current segment offset, denoted pv_off, in pe, i.e., physical block;
s400: and recovering the data according to the logical volume type managed by the logical volume, the section sequence managed by the logical volume and the section quantity.
Specifically, step S400 includes the steps of:
s401: acquiring and judging whether the logical volume type is structed, if yes, executing step S402, otherwise, ending the flow;
in this embodiment, since the type of lvm is stricken, the data is represented as a cluster of logical volume management (JBOD) type, and also represents that the data of the cluster is arranged according to the segment order, and the flow proceeds to step S402;
s402: judging whether the current number of sections is equal to the acquired number of sections, if so, ending the flow, otherwise, executing step S403; in this embodiment, the number of segments (segment_count) is 2.
S403: analyzing the current section, comprising the following steps:
s4031: acquiring the size of the current section according to the acquired section number (segment_count) of 2, wherein the unit is a physical block;
s4032: the information of the fields is read as follows:
the first item value "pv0" of the strips field indicates that the physical volume to which the current section belongs is pv0, and the UUID of pv0 can be obtained according to the foregoing "lv0 in pv data allocation table", and the UUID obtained in step S200 corresponds to the UUID, so that the disk to which the current section belongs can be known;
s4033: the information of the fields is read as follows:
as can be seen from the second term value "0" of the strips field, the offset address of the current segment in the physical volume is 0, which can be denoted as pv_off, and the offset address of the current segment in the disk is calculated by adopting the following formula:
offset address of current sector in disk = offset address of current sector in physical volume × physical block size + physical block start address; that is, pv_off_extension_size+pe_start
S404: and reading the data of each section according to the offset address of each section in the disk and the size of each section, and sequentially combining the data to obtain the cluster data managed by the logical volume, thereby completing the recovery of the cluster data.
The method provided by the invention solves the technical problem that a method for recovering the cluster data managed by the logical volume does not exist in the prior art.
It is to be understood that the invention is not limited to the examples described above, and that modifications and variations may be effected in light of the above teachings by those skilled in the art, all of which are intended to be within the scope of the invention as defined in the appended claims.
Claims (4)
1. A method for recovering cluster data managed by a logical volume is characterized by comprising the following steps:
s100: loading each disk, wherein a disk cluster managed by the logic volume consists of one or more disks, and each logic volume is distributed to the one or more disks;
s200: acquiring each physical volume, and acquiring UUIDs of each physical volume, offset addresses of configuration areas of each physical volume and maximum byte lengths of the configuration areas of each physical volume;
s300: addressing and analyzing a configuration area managed by a logical volume of each physical volume to obtain a volume group, wherein the configuration area comprises description information of the configuration area and data of the configuration area, and the step S300 comprises the following steps:
s301: addressing and analyzing description information of the configuration areas of each physical volume according to offset addresses of the configuration areas of each physical volume, and acquiring the offset addresses of the data of the configuration areas and byte lengths of the data of the configuration areas;
s302: addressing an offset address of the data of the configuration area, and acquiring the data of the configuration area according to the byte length of the data of the configuration area;
s303: analyzing the data of the configuration area to obtain the logical volume type, the physical block size, the physical block starting address, the section sequence and the section number of the logical volume management;
s400: the data recovery is performed according to the logical volume type managed by the logical volume, the zone sequence managed by the logical volume, and the zone number, and the step S400 includes the following steps:
s401: acquiring and judging whether the logical volume type is structed, if yes, executing step S402, otherwise, ending the flow;
s402: judging whether the current number of sections is equal to the acquired number of sections, if so, ending the flow, otherwise, executing step S403;
s403: analyzing the current section, comprising the following steps:
s4031: according to the number of the sections, the size of the current section is obtained, and the unit is a physical block;
s4032: reading information of the strips domain, acquiring a physical volume to which the current section belongs, and acquiring a disk to which the current section belongs according to the UUID;
s4033: reading information of the strips domain, acquiring an offset address of the current section in the physical volume, and calculating the offset address of the current section in the disk by adopting the following formula:
offset address of current sector in disk = offset address of current sector in physical volume × physical block size + physical block start address;
s404: and reading the data of each section according to the offset address of each section in the disk and the size of each section, and sequentially combining the data to obtain the cluster data managed by the logical volume, thereby completing the recovery of the cluster data.
2. The method for restoring cluster data managed by a logical volume according to claim 1, wherein said step S200 comprises the steps of:
s201: the number of addressed sectors gives an initial value of 0;
s202: judging whether the number of the addressed sectors is less than or equal to 8, if yes, executing step S203, otherwise, ending the flow;
s203: reading a currently addressed sector, and the number of addressed sectors = the number of addressed sectors +1;
s204: judging whether each value of the current sector is matched with the structure of the physical volume, if so, executing step S205, otherwise, executing step S202, wherein the metadata information represents that the current sector is raid;
s205: the UUID of the current physical volume is recorded.
3. The method of claim 2, wherein the physical volume structure has a data structure as shown in table one:
data structure of structure body of table-physical volume
Wherein, signature: the physical volume signature managed by the logical volume is fixed as a character string LABELONE, and the corresponding value is 0x454E4F4C4542414C, which is used as an identification for judging whether the current sector is the physical volume;
sector number: offset location of fabric sector of current physical volume;
checksum: checksum, CRC32 checksum from 0x14 bytes to the current identification sector end address;
type indicator: name and version information of logical volume management;
UUID: unique identification of the physical volume represented by ASCII string;
physical volume size: byte length of the logical volume, the unit is bytes;
lvm config area offset: the offset address of the logic volume management configuration area takes the initial address of the disk as the initial address, and the unit is bytes;
lvm config area size: the logical volume manages the byte length of the configuration area in bytes.
4. The method for restoring cluster data managed by a logical volume according to claim 1, wherein the description information of the configuration area has a data structure as shown in the following table two:
data structure of description information of table two configuration area
Wherein, checksum: a CRC32 checksum of the configuration area, which is updated as the data of the configuration area is updated;
signature: configuring a regular character string of the area identifier: "\x20lvm2\x20x [5a% r0n ]"
version information
lvm config area offset: the offset address of the logic volume management configuration area takes the initial address of the disk as the initial address, and the unit is bytes;
lvm config area size: the byte length of the logical volume management configuration area is in bytes;
current lvm config offset: the offset address of the data of the current logical volume management configuration area takes the initial address of the logical volume management configuration area as the initial address, and the unit is bytes;
current lvm config size: the current logical volume manages the byte length of the configuration area in bytes.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911050168.2A CN110825712B (en) | 2019-10-31 | 2019-10-31 | Method for recovering disk cluster data managed by logical volume |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911050168.2A CN110825712B (en) | 2019-10-31 | 2019-10-31 | Method for recovering disk cluster data managed by logical volume |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110825712A CN110825712A (en) | 2020-02-21 |
| CN110825712B true CN110825712B (en) | 2023-08-01 |
Family
ID=69551518
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911050168.2A Active CN110825712B (en) | 2019-10-31 | 2019-10-31 | Method for recovering disk cluster data managed by logical volume |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110825712B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113253945B (en) * | 2021-07-08 | 2021-09-28 | 成都易我科技开发有限责任公司 | Disk coiling clustering method and device and electronic equipment |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0911827B1 (en) * | 1997-10-21 | 2011-11-30 | Sony Corporation | Recording and/or reproduction apparatus, file management method and providing medium |
| CN102508724A (en) * | 2011-10-25 | 2012-06-20 | 北京同有飞骥科技股份有限公司 | Disk bad block processing method based on soft RAID (redundant array of independent disks) |
| US9003227B1 (en) * | 2012-06-29 | 2015-04-07 | Emc Corporation | Recovering file system blocks of file systems |
| CN105487984A (en) * | 2014-09-17 | 2016-04-13 | 中兴通讯股份有限公司 | Dynamic compression method and apparatus for virtual machine disk data by host system |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8713356B1 (en) * | 2011-09-02 | 2014-04-29 | Emc Corporation | Error detection and recovery tool for logical volume management in a data storage system |
| US8935496B2 (en) * | 2012-08-31 | 2015-01-13 | Hitachi, Ltd. | Management method of virtual storage system and remote copy system |
| CN104090829A (en) * | 2014-08-06 | 2014-10-08 | 浪潮电子信息产业股份有限公司 | Method for realizing logical volume metadata backup storage |
| CN104793904B (en) * | 2015-05-07 | 2017-09-15 | 北京银信长远科技股份有限公司 | Logical volume sets hard disk forbidden zone and utilizes the method for hard disk forbidden zone backup configuration information |
| CN105718217B (en) * | 2016-01-18 | 2018-10-30 | 浪潮(北京)电子信息产业有限公司 | A kind of method and device of simplify configuration storage pool data sign processing |
| CN106648474A (en) * | 2017-01-01 | 2017-05-10 | 国云科技股份有限公司 | Virtual machine disk recovery method based on logical volume |
-
2019
- 2019-10-31 CN CN201911050168.2A patent/CN110825712B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0911827B1 (en) * | 1997-10-21 | 2011-11-30 | Sony Corporation | Recording and/or reproduction apparatus, file management method and providing medium |
| CN102508724A (en) * | 2011-10-25 | 2012-06-20 | 北京同有飞骥科技股份有限公司 | Disk bad block processing method based on soft RAID (redundant array of independent disks) |
| US9003227B1 (en) * | 2012-06-29 | 2015-04-07 | Emc Corporation | Recovering file system blocks of file systems |
| CN105487984A (en) * | 2014-09-17 | 2016-04-13 | 中兴通讯股份有限公司 | Dynamic compression method and apparatus for virtual machine disk data by host system |
Non-Patent Citations (1)
| Title |
|---|
| 系统数据恢复技术;倪晟;陈启祥;;软件导刊(第21期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110825712A (en) | 2020-02-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10606491B2 (en) | Providing redundancy in a virtualized storage system for a computer system | |
| US20180173632A1 (en) | Storage device and method for controlling storage device | |
| US9135163B2 (en) | Maintaining versions of data in solid state memory | |
| CN103064765B (en) | Data reconstruction method, device and cluster storage system | |
| US20130332656A1 (en) | File system for maintaining data versions in solid state memory | |
| US10503424B2 (en) | Storage system | |
| CN104461390A (en) | Method and device for writing data into imbricate magnetic recording SMR hard disk | |
| US20140181396A1 (en) | Virtual tape using a logical data container | |
| CN110532136B (en) | Raid data recovery method based on metadata | |
| CN106155589B (en) | A kind of virtual dynamic partition image file generation method and system | |
| US9298551B2 (en) | Efficient incremental updates for shingled magnetic recording (SMR) drives in a RAID configuration | |
| US9135162B2 (en) | Data versioning in solid state memory | |
| CN110825712B (en) | Method for recovering disk cluster data managed by logical volume | |
| CN102623033A (en) | Control method of file system based on rapid video data storage and apparatus | |
| US20150019807A1 (en) | Linearized dynamic storage pool | |
| US20100318585A1 (en) | Method for installing fat file system | |
| CA2893594C (en) | Virtual tape library system | |
| US20040128582A1 (en) | Method and apparatus for dynamic bad disk sector recovery | |
| US9235352B2 (en) | Datastore for non-overwriting storage devices | |
| CN104657471B (en) | Method and system for establishing pre-allocated file of FAT file system | |
| CN111143110B (en) | Metadata-based raid data recovery method in logical volume management | |
| CN111124311B (en) | Method for recovering raid data based on configuration information under logical volume management | |
| CN114327292B (en) | File management method, system, electronic device and storage medium | |
| CN105760313A (en) | Data processing method and device for SPI-Flash-based (Serial Peripheral Interface-Flash-based) file system | |
| CN114217741A (en) | Storage method of storage device and storage device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |