WO2015163696A1 - 마이크로소프트 sql 서버 데이터베이스에서 데이터를 복원하는 방법 및 장치 - Google Patents

마이크로소프트 sql 서버 데이터베이스에서 데이터를 복원하는 방법 및 장치 Download PDF

Info

Publication number
WO2015163696A1
WO2015163696A1 PCT/KR2015/004032 KR2015004032W WO2015163696A1 WO 2015163696 A1 WO2015163696 A1 WO 2015163696A1 KR 2015004032 W KR2015004032 W KR 2015004032W WO 2015163696 A1 WO2015163696 A1 WO 2015163696A1
Authority
WO
WIPO (PCT)
Prior art keywords
record
data
information
column
data file
Prior art date
Application number
PCT/KR2015/004032
Other languages
English (en)
French (fr)
Inventor
이상진
정두원
류기환
최종현
이국헌
장성민
강철훈
전병준
Original Assignee
고려대학교 산학협력단
대한민국(관리부서 검찰청)
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 고려대학교 산학협력단, 대한민국(관리부서 검찰청) filed Critical 고려대학교 산학협력단
Publication of WO2015163696A1 publication Critical patent/WO2015163696A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor

Definitions

  • the present invention relates to a method for restoring data in a Microsoft SQL database, and more particularly, to a method for recovering deleted records remaining in an unallocated area of a database file independent of a transaction log file.
  • Databases which are organized means of information storage, are widely used in all fields where computer data needs to be stored. Companies, in particular, use databases to efficiently manage their work outcomes. Therefore, in the digital forensic investigation process targeting companies, the database becomes an important collection target.
  • SQL Server is a DBMS developed by Microsoft. SQL Server is one of the most popular DBMSs such as Oracle, DB2, and MySQL. It provides high availability and performance through hardware fault tolerance and stabilizer software.
  • SQL Server is one of the most popular DBMSs such as Oracle, DB2, and MySQL. It provides high availability and performance through hardware fault tolerance and stabilizer software.
  • DBMS database management system
  • SQL Server Storage Structures explained the configuration of SQL Server and the structure of database files. Recovering deleted records from these SQL servers makes a lot of sense in terms of digital forensics.
  • the restoration function is performed by recording information necessary for restoration in a separate log file, and then restoring data by using information of the log file at a necessary time.
  • the default setting is left without any setting, only a minimum of information is recorded in the log file, so only some data can be restored. Even if a separate setting is used, all state can be restored to the log file. Without log files, deleted data cannot be restored.
  • the prior art document introduced below introduces a logical error recovery method for a database, and proposes a technique for recovering data through a transaction log.
  • the prior art literature has a fatal drawback that recovery is possible only through transaction logs.
  • the transaction log requires a technical means to recover records deleted from the database independantly.
  • the first problem to be solved by the present invention is to obtain the schema information by using the structural characteristics of the database file, and to extract the deleted record based on the obtained schema information, thereby restoring the data independent of the transaction log To provide a way.
  • the second problem to be solved by the present invention is to obtain the schema information by using the structural characteristics of the database file, and to extract the deleted records based on the obtained schema information, thereby restoring the data independently in the transaction log To provide.
  • the data recovery apparatus receiving a data file from the database; Deriving schema information from the data file by the data restoration apparatus; Identifying, by the data recovery device, an unallocated area within a page of the data file; Extracting, by the data recovery device, the deleted record using the schema information in the unallocated region; And restoring the verified record by the data restoring apparatus verifying the deleted record using the record length value.
  • the database according to the embodiment described above may be a data restoration method characterized in that the Microsoft SQL database.
  • the data file according to the above-described embodiment may have an extension MDF, and may be a data restoration method, wherein table information, column information, and user data of an object created by a user are stored.
  • the deriving of the schema information may include: deriving, by the data restoration apparatus, a first system object including information about a table using a first identification number in the data file; Deriving, by the data recovery apparatus, a second system object including information on a column belonging to a table by using a second identification number in the data file; And deriving the schema information from the derived first system object and the second system object by the data restoration apparatus.
  • the first system object according to the above-described embodiment may distinguish each record according to a record offset arrangement, wherein each record includes an object identification number, an object type, and an object name for each record. It may be a data restoration method.
  • the second system object may distinguish each record according to a record offset arrangement, wherein each record includes information related to one column for each record and is related to the one column.
  • the information may be a data restoration method comprising an object identification number, a column type, and a column name of an object to which the column belongs.
  • the unallocated area according to the above-described embodiment may be a data restoring method, except for a page header, record, and record offset arrangement part of a page of the data file.
  • the record offset including the address of the deleted record offset among the record offsets included in the schema information is changed to 0 when the record is deleted.
  • an input unit for receiving a data file from a database according to an embodiment of the present invention
  • a processing unit for deriving schema information from the data file and identifying an unallocated area within a page of the data file and an extracting unit extracting a deleted record using the schema information in the unallocated region, wherein the extracted record is restored by verifying the deleted record by using a record length value.
  • the processing unit derives a first system object including information about a table using a first identification number in the data file, and uses a second identification number in the data file to display a table. And a second system object including information about a column to which the column belongs, and the schema information is derived from the derived first system object and the second system object.
  • the first system object according to the above-described embodiment may distinguish each record according to a record offset arrangement, wherein each record includes an object identification number, an object type, and an object name for each record. It may be a data recovery device.
  • the second system object may distinguish each record according to a record offset arrangement, wherein each record includes information related to one column for each record and is related to the one column.
  • the information may be a data restoration apparatus including an object identification number, a column type, and a column name of an object to which the column belongs.
  • the unallocated area according to the above-described embodiment may be a data restoring device, except for a page header, a record, and a record offset arrangement part of a page of the data file.
  • the record offset including the address of the deleted record offset among the record offsets included in the schema information is changed to 0 when the record is deleted.
  • FIG. 1 is a flowchart illustrating a data restoration method adopted by one embodiment of the present invention.
  • FIG. 2 is a diagram showing the structure of a SQL server database according to an embodiment of the present invention.
  • FIG. 3 is a diagram illustrating a 'sysschobis' page including table information according to an embodiment of the present invention.
  • FIG. 4 is a diagram illustrating a 'syscolpars' page including column information according to an embodiment of the present invention.
  • FIG. 5A illustrates a page structure according to an embodiment of the present invention.
  • 5B is a diagram illustrating a page header structure according to an embodiment of the present invention.
  • 5C illustrates a data page structure according to an embodiment of the present invention.
  • FIG. 6 is a diagram illustrating a change of a record offset according to record deletion according to an embodiment of the present invention.
  • FIG. 7A illustrates a record change for a 'sysschobjs' page according to a table deletion according to an embodiment of the present invention.
  • FIG. 7B is a diagram illustrating a change of a record offset for a 'sysschobjs' page according to a table deletion according to an embodiment of the present invention.
  • FIG. 8 illustrates a record structure according to an embodiment of the present invention.
  • FIG. 9A is another flowchart illustrating the data restoration method of FIG. 1, according to an exemplary embodiment.
  • FIG. 9B is a flowchart illustrating step S960 of FIG. 9A according to an embodiment of the present invention in more detail.
  • FIG. 10 is a block diagram illustrating a data recovery apparatus employed in one embodiment of the present invention.
  • the database contains important information, which is likely to have meaningful information from a digital forensic point of view. It is important to extract normal records from the database, but also to recover deleted records.
  • research on restoring database data is based on transaction logs. However, there is a fatal disadvantage that this method cannot be used if the transaction log does not exist or if you want to restore the previous point data recorded by the transaction log.
  • embodiments of the present invention are technical means capable of restoring deleted records remaining in an unallocated region by using the structural characteristics of a database file for SQL server after obtaining schema information from a database non-dependently of a transaction log.
  • the data recovery device receives a data file from a database, derives schema information from the data file, identifies an unallocated area within a page of the data file, and extracts deleted records using the schema information from the unallocated area.
  • the verified record is recovered by verifying the deleted record using the record length value.
  • FIG. 1 is a flowchart illustrating a data restoration method adopted by an embodiment of the present invention, in which a data restoration apparatus receives a data file from a database, derives schema information from the data file, and displays a page of the data file. Identifying an unallocated area, extracting a deleted record using the schema information in the unallocated area, and verifying the deleted record by using a record length value for the deleted record, thereby recovering the verified record.
  • step S110 the data recovery device receives a data file from the database.
  • FIG. 2 is a diagram showing the structure of a SQL server database according to an embodiment of the present invention.
  • the SQL server has an extension mdf file 22 and an extension ldf file 23 for each database 21.
  • the extension mdf file 22 has a file format of 'DB name.mdf', stores an object created by a user, and may include table information, column information, and actual data.
  • related information about the structure of the database 21 may be stored, actual data may be stored, and the file may be composed of several pages.
  • the page size may be 8192 (0x2000) bytes.
  • extension ldf file 23 has a file type of 'DB name _log.ldf', stores a transaction created by a user, and can create and delete a table, insert and delete data, and change history. In addition, it stores a record of the Database Manipulation Language (DML) and Database Definition Language (DDL) execution, and can record data in units of transactions for all operations occurring in the database 21.
  • DML Database Manipulation Language
  • DDL Database Definition Language
  • the present invention is a method for restoring data that is not dependently deleted in the transaction login extension ldf file 23, the table information, column information, And by acquiring user data, it can be used for data restoration.
  • the data restoration apparatus derives schema information from the data file.
  • the data recovery apparatus derives a first system object including information about a table using a first identification number in the data file, and uses a second identification number in the data file to assign a column belonging to a table.
  • a second system object including information about the second system object may be derived, and the schema information may be derived from the derived first system object and the second system object.
  • the first system object may distinguish each record according to a record offset arrangement, wherein each record includes an object identification number, an object type, and an object name for each record, and the second system object includes a record
  • Each record may be classified according to an offset array, and each record includes information related to one column for each record, and the information related to one column may include an object identification number, a type of a column, And column names.
  • a Microsoft SQL Server database can classify and manage data by objects, which are logical units such as tables or views.
  • Objects include user-defined tables and views, and system tables and system views, which are basically maintained for internal management in a Microsoft SQL Server database.
  • Each object is assigned an object identification number, which is a unique identifier, and a system object has a predetermined value because an object identification number is defined in advance, and a user-defined object may be assigned a new object identification number at creation.
  • the Microsoft SQL Server database can include a number of system objects by default to efficiently manage internal structure.
  • the first object identification number of the 'sysschobjs' may be 34
  • the second object identification number of the 'syscolpars' may be 41.
  • FIG. 3 is a diagram illustrating a 'sysschobis' page including table information according to an embodiment of the present invention, and may be a record in a page related to the system object 'sysschobjs'.
  • the system object 'sysschobjs' and the system object 'sysschobjs' are found by finding a page having a value of 'Version' field, 01, 'Page Type' field value of 01, and 'Object ID' field value of 34. Find related pages.
  • the field value is 01
  • this may mean a data page.
  • information about each table is managed in the form of records in the 'sysschobjs' page as shown in FIG. 3 and each record can be identified by referring to the record offset array existing at the end of the page.
  • Each record includes information related to one object and includes information such as an object identification number, an object type, and an object name. Among them, records related to user-defined tables can be distinguished, and table-related information can be obtained therefrom.
  • FIG. 4 is a diagram illustrating a 'syscolpars' page including column information according to an embodiment of the present invention, and may be a record in the system object 'syscoplars' related page.
  • the table related information may be a signature 31, a table object ID 32, a number of columns 33, and a column name 34.
  • the system object 'syscolpars' and the system object 'syscolpars' are searched for by finding a page having a 'Version' field value of 01, a 'Page Type' field value of 01, and an 'Object ID' field value of 41. Find related pages.
  • the field value is 01
  • this may mean a data page
  • column information of all tables existing in the database is managed in a record form in the 'syscolpars' page, and an array of record offsets existing at the end of the page. You can check each record by referring to.
  • Each record includes information related to one column and includes information such as the object identification number of the object to which the column belongs, the type of the column, and the column name.
  • column information of each table may be obtained by dividing a record including the object identification number and extracting information therefrom.
  • the column information of the table may be a signature 41, a column length 42, a table object ID 43, a column order 44, a column name 45, and a data type 46.
  • the value for the data type 46 may be as shown in Table 1 below.
  • Table 1 Data type type value type value bigint 0x7F7F binary 0xADAD bit 0x6868 char 0xAFAF date 0x2828 datetime 0x3D3D datetime2 0x2A2A datetimeoffset 0x2B2B decimal 0x6A6A float 0x3E3E geography 0x82F0 geometry 0x81F0 hierachyid 0x80F0 image 0x2222 int 0x3838 money 0x3C3C nchar 0xEFEF ntext 0x6363 numeric 0x6C6C nvarchar 0xE7E7 nvarchar (MAX) 0xE7E7 real 0x3B3B smalldatetime 0x3A3A smallint 0x3434 smallmoney 0x7A7A sql_variant 0x6262 text 0x2323 time 0x292929
  • the data recovery apparatus identifies an unallocated area within a page of the data file.
  • the unallocated area may be the remaining part except the page header, record, and record offset arrangement part of the page of the data file.
  • the data file input in step S110 is configured in units of pages, and various types of pages may exist in the data file.
  • the data page will be described in more detail with reference to FIG. 5 below.
  • FIG. 5A illustrates a page structure according to an embodiment of the present invention.
  • the minimum unit of input and output is 'page', and one object is allocated one or more pages, and the page size may vary depending on the user definition. It can be 8192 bytes.
  • Each page may include a page header 51, a record data row 52, and a row offset array 53.
  • the page header 51 may include page type, the number of records in the page, and the like, which are basic information about the page.
  • the record area 52 includes actual data, and the start of each record can be referred to through the record offset array.
  • the record offset 53 is an array of 2-byte units containing information about the start position of each record, stored in reverse order from the last part of the page, and the offset space allocated for pointing to each record is It can be 2 bytes. Therefore, since the offset space is an array of 2 bytes, the offset may be indicated by 2 bytes of data.
  • the structure of the page header 51 may be expressed as shown in FIG. 5B, the page header structure may be allocated 60 bytes of space, and the number of records existing in the page is the 'SlotCnt' field 54 of the page header. You can find it at Here, the page header 51 is actually 96 bytes, 60 bytes of the 96 bytes contain meaningful information, and the remaining 36 bytes are mostly composed of 0x00.
  • the page may be divided into a page header 51, a record area 52, and a record offset 53.
  • the unallocated area 55 may exist in the record area 52. That is, the unallocated area 55 may exist between the header and the record included in the record area 52, between the record and the record, and between the record and the record offset.
  • the square box parts are 0xF: 2060 and 0xF: 2146 parts are the first starting positions of the records indicated by the record offset 53, and the record length of 0xF: 2146 is 32 bytes, so 0xF: 2080 to 0xF.
  • Up to 2145 may be an unallocated area 55 that is not indicated by the record offset 53, that is, an unallocated area existing between the record and the record.
  • the data recovery apparatus extracts the deleted record using the schema information in the unallocated region.
  • the actual data portion of the deleted record remains in the unallocated region, and the record offset portion indicating the portion may be changed to zero.
  • FIG. 6 is a diagram illustrating a change of a record offset according to record deletion according to an embodiment of the present invention, and it can be seen that the record offset 61 before the record deletion is changed to the record offset 62 after the record deletion.
  • the record is analyzed in the unallocated region identified in step S130 by referring to the record offset changed due to the record deletion, and the table information extracted from the analyzed record is included in the extracted table information and the schema information obtained in step S120. By comparing the table information, if the table structure is the same, the deleted record can be extracted.
  • FIG. 7A and 7B illustrate the change of the 'sysschobjs' page according to the deletion of the int_table.
  • FIG. 7A the change of the record according to the deletion of the int_table is shown.
  • step S150 the data recovery apparatus verifies the deleted record by using the record length value to recover the verified record.
  • the type of record is a fixed length record structure 81 consisting of only columns having a fixed length in the record as shown in FIG. 8 and a variable length record structure 82 including a column having a variable length in the record. It can be divided into two.
  • a fixed length record structure 81 consisting of only columns having a fixed length in the record as shown in FIG. 8
  • variable length record structure 82 including a column having a variable length in the record. It can be divided into two.
  • to verify whether fixed-length record structures 81 or variable-length record structures 82 are in unallocated regions, depending on the columns of the table at the first byte of the record, at the position indicated by the status bit value and at position 0x3. Compares whether the number of columns is equal to the number of columns in the table to be restored.
  • variable length columns If there are variable length columns, the number of variable length columns is verified, the total length of the record is calculated based on the length information of each data present in the record, and the length value of the corresponding record is determined from the number of columns and column information obtained from the table information. Valid records are identified by verifying whether they are equal to the obtained column length.
  • the length of the record extracted from the unallocated region identified through the step S150 is calculated, and if the extracted record is a record having a normal structure, an additional record exists between the end of the corresponding record and the end of the unallocated region. If there is an additional record, the process of verifying whether the record is present may be repeated in step S150 with respect to the additional record.
  • FIG. 9A the data restoration method of FIG. 1 may be expressed as another flowchart as shown in FIG. 9A below.
  • FIG. 9A is another flowchart illustrating the data restoration method of FIG. 1, according to an exemplary embodiment. More specifically, in step S910, from the Master database, which is a system database that contains information needed to efficiently manage Microsoft SQL Server, You can obtain information about the DB that has been disconnected or deleted.
  • the Master database which is a system database that contains information needed to efficiently manage Microsoft SQL Server.
  • step S920 by checking whether there is a disconnected DB or a deleted DB among the information obtained in step S910, the process proceeds to step S930 if there is one, and if it does not exist, step S950.
  • step S930 by checking the path information of the information obtained in step S910 to check whether there is an MDF file of the disconnected or deleted DB, the process proceeds to step S950, and if not present, step S940.
  • the MDF file may be carved to the system.
  • the system is a DBMS system, and the carving refers to a method of scanning and restoring a data area.
  • the carving may be a method of restoring using a characteristic structure and signature different from other data.
  • a verification operation may be performed on the input MDF file by comparing name information in the MDF file with information obtained from a master.
  • step S960 the deleted data may be restored by performing a recovery process for each DB for the MDF file verified in operation S950.
  • step S960 will be described in more detail with reference to FIG. 9B below.
  • FIG. 9B is a flowchart illustrating step S960 of FIG. 9A according to an embodiment of the present invention in more detail, and includes a configuration corresponding to each process of FIG. 1 described above. Therefore, the function of each process will be outlined here to avoid duplication of explanation.
  • table information may be obtained by receiving a data file having an extension of MDF.
  • table information may be collected by searching the 'sysschobjs' page included in the data file, and column information about the table may be collected by searching the 'syscolpars' page.
  • the MDF file is composed of pages. Therefore, the data page can be repeatedly searched by skipping by one page from the first page which is the start page to the last page which exists at the end of the file.
  • the record offset array may be collected and sorted in ascending order with respect to the record offset array. Then, after accessing the data page, the records existing in the data page are accessed. The following process is repeated as many as the number of offsets present in the row offset array from the first of the row offset array.
  • the first record position can be accessed by using the value in the Row Offset Array array as the address. Since the record length can vary depending on the number of columns and the data type of the table to which the record belongs, you can calculate the length of the record through the internal information of the record. In this case, the calculated length of the record may be referred to as P.
  • the random variable T repeats the following process from 1 to the total number of Row Offset Arrays.
  • T 5
  • the first position of the record is accessed using the fifth value in the row offset array, and then the length of the record is calculated.
  • the length of the deleted record is calculated by extracting the record existing from the position of the current record (OFFSET (T) + P + 1) to the next offset (OFFSET (T + 1) -1). By verifying, you can recover the deleted record by outputting the verified record.
  • FIG. 10 is a block diagram illustrating a data restoration apparatus employed in one embodiment of the present invention, and the data restoration apparatus 100 includes a configuration corresponding to each process of FIG. 1 described above. Therefore, in order to avoid duplication of description, the function of the system will be outlined in detail.
  • the input unit 101 receives a data file from a database.
  • the processor 102 derives schema information from the data file and identifies an unallocated area within a page of the data file.
  • the extraction unit 103 extracts the deleted record using the schema information in the unallocated area, and restores the verified record by verifying the deleted record using the record length value.
  • the processing unit 102 derives a first system object including information about a table using a first identification number in the data file, and uses a second identification number in the data file to assign a column belonging to a table.
  • a second system object including information about the second system object may be derived, and the schema information may be derived from the derived first system object and the second system object.
  • the first system object may distinguish each record according to a record offset arrangement, and each record may include an object identification number, an object type, and an object name for each record.
  • the second system object may distinguish each record according to a record offset arrangement, wherein each record includes information related to one column for each record, and the information related to the one column belongs to a column. It may include the object identification number of the object, the type of the column, and the column name.
  • the unallocated region may be a portion other than the page header, record, and record offset arrangement portion of the page of the data file.
  • the record offset including the address of the deleted record offset among the record offsets included in the schema information may be changed to zero.
  • a data restoration tool was produced in connection with the data restoration method of the present invention, and restoration was performed in consideration of all data deleted from a Microsoft SQL Server database.
  • the input to the data restoration tool is a data file of the Microsoft SQL Server database with the mdf extension, obtains schema information from the data file, attempts to restore it based on the obtained information, and extracts all deleted records. If you do, you can see that the deleted records are extracted normally.
  • the embodiments of the present invention can be implemented in computer readable codes on a computer readable recording medium.
  • the computer-readable recording medium includes all kinds of recording devices in which data that can be read by a computer system is stored.
  • Examples of computer-readable recording media include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, and the like.
  • the computer readable recording medium can also be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.
  • functional programs, codes and code segments for implementing the present invention can be easily inferred by programmers in the art to which the present invention belongs.
  • the transaction log due to the company policy or database settings
  • deleting there is an effect of recovering data even when there is no transaction log.
  • a suspect deliberately deletes data from a digital forensic point of view, it is possible to recover the data and prove evidence and deletion.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

마이크로소프트 SQL 서버 데이터베이스에서 데이터를 복원하는 방법 및 장치에 관한 것으로서, 데이터 복원 장치가 데이터베이스로부터 데이터 파일을 입력받고, 데이터 파일로부터 스키마 정보를 도출하고, 데이터 파일의 페이지 내 비 할당 영역을 식별하고, 비 할당 영역에서 스키마 정보를 이용하여 삭제된 레코드를 추출하며, 삭제된 레코드에 대하여 레코드의 길이 값을 이용하여 검증함으로써, 검증된 레코드를 복구한다.

Description

마이크로소프트 SQL 서버 데이터베이스에서 데이터를 복원하는 방법 및 장치
본 발명은 마이크로소프트 SQL 데이터베이스에서 데이터를 복원하는 방법에 관한 것으로, 특히 트랜잭션 로그 파일에 비종속적으로 데이터베이스 파일의 비 할당 영역에 잔존하는 삭제된 레코드를 복구하는 방법에 관한 것이다.
체계화된 정보 저장 수단인 데이터베이스는 전산데이터를 보관할 필요가 있는 모든 분야에서 광범위하게 사용되고 있다. 특히 기업의 경우 조직의 업무 결과물을 효율적으로 관리하기 위해 데이터베이스를 사용하고 있다. 따라서, 기업을 대상으로 하는 디지털 포렌식 수사과정에서 데이터베이스는 중요한 수집 대상이 된다.
데이터베이스를 대상으로 증거 수집 시 정상적인 데이터를 수집하는 것도 중요하지만, 사용자가 의도적으로 민감한 데이터를 삭제할 가능성이 존재하기 때문에 삭제된 데이터를 복구하는 기법에 대해 연구가 필요하다.
SQL 서버는 마이크로소프트에서 개발한 DBMS이다. SQL 서버는 오라클, DB2, MySQL과 같이 많이 쓰이는 DBMS 중 하나이며, 하드웨어 고장 감내성 및 안정장치 소프트웨어를 통해 뛰어난 가용성과 성능을 제공한다. 2007년 Ken England와 Gavin Powell이 쓴 논문인 “SQL Server Storage Structures”에서 SQL 서버의 구성과 데이터베이스 파일 구조에 대해서 설명하였다. 이러한 SQL 서버에서 삭제된 레코드를 복구하는 것은 디지털 포렌식 관점에 있어서 많은 의미가 있다.
마이크로소프트 SQL 서버 데이터베이스에서는 기본적으로 제공하는 복원 기능이 존재한다. 상기 복원 기능은 복원에 필요한 정보를 별도의 로그파일에 기록하고, 이후 필요한 시점에 로그 파일의 정보를 활용하여 데이터를 복원하는 방식으로 이루어진다. 그러나 별도의 설정을 하지 않고 기본 설정 그대로인 경우에는, 최소한의 정보만 로그 파일에 기록되기 때문에 일부 데이터만 복원이 가능하며, 만일 별도의 설정을 통해 모든 상태가 복원이 가능하도록 로그 파일에 기록하였다 하더라도 로그 파일이 없으면 삭제된 데이터의 복원이 불가능하다.
한편, 이하에서 소개되는 선행기술 문헌에는 데이터베이스의 논리적 오류 복구방법을 소개하고, 트랜잭션 로그를 통해 데이터를 복구하는 기술을 제안하고 있다. 하지만, 선행기술 문헌은 트랜잭션 로그를 통해서만 복구가 가능하다는 치명적인 단점이 존재한다.
(선행기술문헌) 공개특허공보 제10-2010-0134355호 (2010.12.23)
이와 같은 관점에서, 트랜잭션 로그에 비종속적으로 데이터베이스에서 삭제된 레코드를 복구할 수 있는 기술적 수단이 필요하다는 사실을 알 수 있다.
따라서, 본 발명이 해결하고자 하는 첫 번째 과제는 데이터베이스 파일의 구조적 특징을 이용하여 스키마 정보를 획득하고, 획득한 스키마 정보에 기초하여 삭제된 레코드를 추출함으로써, 트랜잭션 로그에 비종속적으로 데이터를 복원하는 방법을 제공하는 것이다.
본 발명이 해결하고자 하는 두 번째 과제는 데이터베이스 파일의 구조적 특징을 이용하여 스키마 정보를 획득하고, 획득한 스키마 정보에 기초하여 삭제된 레코드를 추출함으로써, 트랜잭션 로그에 비종속적으로 데이터를 복원하는 장치를 제공하는 것이다.
상기 첫 번째 과제를 해결하기 위하여, 본 발명의 일 실시예에 따른 데이터 복원 장치가 데이터베이스로부터 데이터 파일을 입력받는 단계; 상기 데이터 복원 장치가 상기 데이터 파일로부터 스키마 정보를 도출하는 단계; 상기 데이터 복원 장치가 상기 데이터 파일의 페이지 내 비 할당 영역을 식별하는 단계; 상기 데이터 복원 장치가 상기 비 할당 영역에서 상기 스키마 정보를 이용하여 삭제된 레코드를 추출하는 단계; 및 상기 데이터 복원 장치가 상기 삭제된 레코드에 대하여 레코드의 길이 값을 이용하여 검증함으로써, 검증된 레코드를 복구하는 단계를 포함하는 데이터 복원 방법을 제공한다.
상기된 일 실시예에 따른 상기 데이터베이스는 마이크로소프트 SQL 데이터베이스인 것을 특징으로 하는 데이터 복원 방법일 수 있다.
상기된 일 실시예에 따른 상기 데이터 파일은 확장자 명 MDF이고, 사용자가 생성한 객체의 테이블 정보, 컬럼정보, 및 사용자 데이터를 저장하는 것을 특징으로 하는 데이터 복원 방법일 수 있다.
상기된 일 실시예에 따른 상기 스키마 정보를 도출하는 단계는, 상기 데이터 복원 장치가 상기 데이터 파일에서 제 1 식별 번호를 이용하여 테이블에 대한 정보를 포함하는 제 1 시스템 객체를 도출하는 단계; 상기 데이터 복원 장치가 상기 데이터 파일에서 제 2 식별 번호를 이용하여 테이블에 속하는 컬럼에 대한 정보를 포함하는 제 2 시스템 객체를 도출하는 단계; 및 상기 데이터 복원 장치가 상기 도출된 제 1 시스템 객체 및 제 2 시스템 객체로부터 상기 스키마 정보를 도출하는 단계를 포함하는 데이터 복원 방법일 수 있다.
상기된 일 실시예에 따른 상기 제 1 시스템 객체는, 레코드 오프셋 배열에 따라 각각의 레코드를 구분할 수 있으며, 상기 각각의 레코드는 레코드별로 객체 식별 번호, 객체의 타입, 및 객체 이름을 포함하는 것을 특징으로 하는 데이터 복원 방법일 수 있다.
상기된 일 실시예에 따른 상기 제 2 시스템 객체는, 레코드 오프셋 배열에 따라 각각의 레코드를 구분할 수 있고, 상기 각각의 레코드는 레코드별로 하나의 컬럼과 관련된 정보를 포함하며, 상기 하나의 컬럼과 관련된 정보는 컬럼이 속한 객체의 객체 식별 번호, 컬럼의 타입, 및 컬럼 이름을 포함하는 것을 특징으로 하는 데이터 복원 방법일 수 있다.
상기된 일 실시예에 따른 상기 비 할당 영역은 상기 데이터 파일의 페이지 내 페이지 헤더, 레코드, 레코드 오프셋 배열 부분을 제외한 나머지 부분인 것을 특징으로 하는 데이터 복원 방법일 수 있다.
상기된 일 실시예에 따른 상기 레코드가 삭제될 경우 상기 스키마 정보에 포함된 레코드 오프셋 중 상기 삭제된 레코드 오프셋의 주소를 포함하는 레코드 오프셋이 0으로 변경되는 것을 특징으로 하는 데이터 복원 방법일 수 있다.
상기된 두 번째 과제를 해결하기 위하여, 본 발명의 일 실시예에 따른 데이터베이스로부터 데이터 파일을 입력받는 입력부; 상기 데이터 파일로부터 스키마 정보를 도출하고, 상기 데이터 파일의 페이지 내 비 할당 영역을 식별하는 처리부; 및 상기 비 할당 영역에서 상기 스키마 정보를 이용하여 삭제된 레코드를 추출하는 추출부를 포함하되, 상기 삭제된 레코드에 대하여 레코드의 길이 값을 이용하여 검증함으로써, 검증된 레코드를 복구하는 것을 특징으로 하는 데이터 복원 장치를 제공한다.
상기된 일 실시예에 따른 상기 처리부는, 상기 데이터 파일에서 제 1 식별 번호를 이용하여 테이블에 대한 정보를 포함하는 제 1 시스템 객체를 도출하고, 상기 데이터 파일에서 제 2 식별 번호를 이용하여 테이블에 속하는 컬럼에 대한 정보를 포함하는 제 2 시스템 객체를 도출하며, 상기 도출된 제 1 시스템 객체 및 제 2 시스템 객체로부터 상기 스키마 정보를 도출하는 것을 특징으로 하는 데이터 복원 장치일 수 있다.
상기된 일 실시예에 따른 상기 제 1 시스템 객체는, 레코드 오프셋 배열에 따라 각각의 레코드를 구분할 수 있으며, 상기 각각의 레코드는 레코드별로 객체 식별 번호, 객체의 타입, 및 객체 이름을 포함하는 것을 특징으로 하는 데이터 복원 장치일 수 있다.
상기된 일 실시예에 따른 상기 제 2 시스템 객체는, 레코드 오프셋 배열에 따라 각각의 레코드를 구분할 수 있고, 상기 각각의 레코드는 레코드별로 하나의 컬럼과 관련된 정보를 포함하며, 상기 하나의 컬럼과 관련된 정보는 컬럼이 속한 객체의 객체 식별 번호, 컬럼의 타입, 및 컬럼 이름을 포함하는 것을 특징으로 하는 데이터 복원 장치일 수 있다.
상기된 일 실시예에 따른 상기 비 할당 영역은 상기 데이터 파일의 페이지 내 페이지 헤더, 레코드, 레코드 오프셋 배열 부분을 제외한 나머지 부분인 것을 특징으로 하는 데이터 복원 장치일 수 있다.
상기된 일 실시예에 따른 상기 레코드가 삭제될 경우 상기 스키마 정보에 포함된 레코드 오프셋 중 상기 삭제된 레코드 오프셋의 주소를 포함하는 레코드 오프셋이 0으로 변경되는 것을 특징으로 하는 데이터 복원 장치일 수 있다.
본 발명에 따르면, 데이터 파일로부터 스키마 정보를 획득하고, 삭제된 레코드가 존재하는 비 할당 데이터 영역에 접근하여 스키마 정보를 이용하여 삭제된 레코드를 복구함으로써, 회사 정책이나 데이터베이스 설정으로 인한 트랜잭션 로그가 존재하지 않더라도 레코드를 복구할 수 있는 효과가 있다.
도 1은 본 발명의 일 실시예들이 채택하고 있는 데이터 복원 방법을 도시한 흐름도이다.
도 2는 본 발명의 일 실시예에 따른 SQL 서버 데이터베이스의 구조를 도시한 도면이다.
도 3은 본 발명의 일 실시예에 따른 테이블 정보를 포함하는 'sysschobis' 페이지를 도시한 도면이다.
도 4는 본 발명의 일 실시예에 따른 컬럼 정보를 포함하는 'syscolpars' 페이지를 도시한 도면이다.
도 5a는 본 발명의 일 실시예에 따른 페이지 구조를 도시한 도면이다.
도 5b은 본 발명의 일 실시예에 따른 페이지 헤더 구조를 도시한 도면이다.
도 5c는 본 발명의 일 실시예에 따른 데이터 페이지 구조를 도시한 도면이다.
도 6은 본 발명의 일 실시예에 따른 레코드 삭제에 따른 레코드 오프셋의 변화를 도시한 도면이다.
도 7a은 본 발명의 일 실시예에 따른 테이블 삭제에 따른 'sysschobjs' 페이지에 대한 레코드 변화를 도시한 도면이다.
도 7b는 본 발명의 일 실시예에 따른 테이블 삭제에 따른 'sysschobjs' 페이지에 대한 레코드 오프셋의 변화를 도시한 도면이다.
도 8은 본 발명의 일 실시예에 따른 레코드 구조를 도시한 도면이다.
도 9a는 본 발명의 일 실시예에 따른 도 1의 데이터 복원 방법을 도시한 또 다른 흐름도이다.
도 9b는 본 발명의 일 실시예에 따른 도 9a의 S960 단계를 보다 구체적으로 도시한 흐름도이다.
도 10은 본 발명의 일 실시예들이 채택하고 있는 데이터 복원 장치를 도시한 블럭도이다.
<부호의 설명>
100 : 데이터 복원 장치
101 : 입력부
102 : 처리부
103 : 추출부
본 발명의 실시예들을 설명하기에 앞서, 기존의 데이터 복원 방법에서 발생하는 문제점들을 검토한 후, 이들 문제점을 해결하기 위해 본 발명의 실시예들이 채택하고 있는 기술적 수단을 개괄적으로 소개하도록 한다.
데이터베이스에는 중요한 정보가 저장되어 있어 디지털 포렌식 관점에서 의미 있는 정보가 있을 확률이 높다. 데이터베이스에서 정상적인 레코드를 추출하는 것도 중요하지만 삭제된 레코드를 복구하는 것도 중요하다. 현재 데이터베이스 데이터 복원에 대한 연구는 트랜잭션 로그를 기반으로 복원한다. 하지만, 이 방법은 트랜잭션 로그가 존재하지 않거나 트랜잭션 로그가 기록한 이전시점의 데이터를 복원하고 싶은 경우에는 사용할 수 없다는 치명적인 단점이 존재한다.
따라서, 본 발명의 실시예들은 트랜잭션 로그의 비종속적으로 데이터베이스로부터 스키마 정보를 획득한 후 SQL 서버에 대한 데이터베이스 파일의 구조적 특성을 이용하여 비 할당 영역에 잔존하는 삭제된 레코드를 복원할 수 있는 기술적 수단으로서, 데이터 복원 장치가 데이터베이스로부터 데이터 파일을 입력받고, 데이터 파일로부터 스키마 정보를 도출하고, 데이터 파일의 페이지 내 비 할당 영역을 식별하고, 비 할당 영역에서 스키마 정보를 이용하여 삭제된 레코드를 추출하며, 삭제된 레코드에 대하여 레코드의 길이 값을 이용하여 검증함으로써, 검증된 레코드를 복구한다.
이하에서는 도면을 참조하여 본 발명의 실시예들을 구체적으로 설명하도록 한다. 다만, 하기의 설명 및 첨부된 도면에서 본 발명의 요지를 흐릴 수 있는 공지 기능 또는 구성에 대한 상세한 설명은 생략한다. 또한, 도면 전체에 걸쳐 동일한 구성 요소들은 가능한 한 동일한 도면 부호로 나타내고 있음에 유의하여야 한다.
도 1은 본 발명의 일 실시예들이 채택하고 있는 데이터 복원 방법을 도시한 흐름도로서, 데이터 복원 장치가 데이터베이스로부터 데이터 파일을 입력받고, 상기 데이터 파일로부터 스키마 정보를 도출하고, 상기 데이터 파일의 페이지 내 비 할당 영역을 식별하고, 상기 비 할당 영역에서 상기 스키마 정보를 이용하여 삭제된 레코드를 추출하며, 상기 삭제된 레코드에 대하여 레코드의 길이 값을 이용하여 검증함으로써, 검증된 레코드를 복구한다.
보다 구체적으로 S110 단계에서, 데이터 복원 장치가 데이터베이스로부터 데이터 파일을 입력받는다.
다시 말해, SQL 서버 데이터베이스에서 삭제된 레코드를 복구하기 위해서는 데이터베이스 구조에 대해서 알아야 한다. 여기서, 상기 데이터베이스 구조는 이하에서 도 2를 통해 보다 구체적으로 설명하도록 한다.
도 2는 본 발명의 일 실시예에 따른 SQL 서버 데이터베이스의 구조를 도시한 도면이다.
상기 SQL 서버는 하나의 데이터베이스(21)마다 확장자 mdf 파일(22) 및 확장자 ldf 파일(23)이 존재한다. 여기서, 확장자 mdf 파일(22)은 'DB명.mdf'의 파일 형식을 가지고, 사용자가 생성한 객체를 저장하며, 테이블 정보, 컬럼정보, 및 실제 데이터를 포함할 수 있다. 또한, 데이터베이스(21) 구조에 대한 관련 정보를 저장하고, 실제적인 데이터가 저장될 수 있으며, 파일은 여러 개의 페이지로 구성될 수 있다. 상기 페이지 크기는 8192(0x2000) 바이트일 수 있다.
또한, 확장자 ldf 파일(23)은 'DB명_log.ldf'의 파일 형식을 가지고, 사용자가 생성한 트랜잭션을 저장하며, 테이블의 생성과 삭제, 데이터 삽입과 삭제 및 변경 내역을 저장할 수 있다. 또한, DML(Database Manipulation Language) 과 DDL(Database Definition Language) 실행에 대한 기록을 저장하며, 데이터베이스(21) 내에서 발생하는 모든 작업을 트랜잭션 단위로 데이터를 기록할 수 있다.
따라서, 본 발명은 상기 트랙잭션 로그인 확장자 ldf 파일(23)에 비종속적으로 삭제된 데이터를 복원하는 방법이므로, 상기 데이터 파일인 확장자 명 MDF 파일을 입력받아 사용자가 생성한 객체의 테이블 정보, 컬럼정보, 및 사용자 데이터를 획득함으로써, 데이터 복원에 사용할 수 있다.
이제 다시 도 1로 돌아가 S110 단계 이후를 설명하도록 한다.
S120 단계에서, 상기 데이터 복원 장치가 상기 데이터 파일로부터 스키마 정보를 도출한다. 다시 말해, 상기 데이터 복원 장치가 상기 데이터 파일에서 제 1 식별 번호를 이용하여 테이블에 대한 정보를 포함하는 제 1 시스템 객체를 도출하고, 상기 데이터 파일에서 제 2 식별 번호를 이용하여 테이블에 속하는 컬럼에 대한 정보를 포함하는 제 2 시스템 객체를 도출하며, 상기 도출된 제 1 시스템 객체 및 제 2 시스템 객체로부터 상기 스키마 정보를 도출할 수 있다. 또한, 상기 제 1 시스템 객체는 레코드 오프셋 배열에 따라 각각의 레코드를 구분할 수 있고, 상기 각각의 레코드는 레코드별로 객체 식별 번호, 객체의 타입, 및 객체 이름을 포함하고, 상기 제 2 시스템 객체는 레코드 오프셋 배열에 따라 각각의 레코드를 구분할 수 있고, 상기 각각의 레코드는 레코드별로 하나의 컬럼과 관련된 정보를 포함하며, 상기 하나의 컬럼과 관련된 정보는 컬럼이 속한 객체의 객체 식별 번호, 컬럼의 타입, 및 컬럼 이름을 포함할 수 있다.
보다 구체적으로, 마이크로소프트 SQL 서버 데이터베이스는 논리적으로 테이블이나 뷰와 같이 논리적인 단위인 객체별로 데이터를 분류하고 관리할 수 있다. 객체에는 사용자가 정의한 테이블이나 뷰 등이 포함되며, 마이크로소프트 SQL 서버 데이터베이스에서 내부 관리를 위해 기본적으로 보유하고 있는 시스템 테이블, 시스템 뷰도 이에 포함될 수 있다. 상기 각각의 객체마다 고유 식별자인 객체 식별 번호가 부여되며, 시스템 객체는 객체 식별 번호가 사전에 정의되어 있어 일정한 값을 가지게 되고 사용자가 정의한 객체는 생성 시 새로운 객체 식별 번호가 부여될 수 있다.
이와 같이, 마이크로소프트 SQL 서버 데이터베이스는 내부 구조를 효율적으로 관리하기 위하여 기본적으로 다수의 시스템 객체들을 포함할 수 있다. 이 중에서, 데이터베이스 내 테이블에 대한 정보와 각 테이블에 속하는 컬럼에 대한 정보를 관리하는 시스템 객체가 존재하고, 테이블에 대한 정보는 상기 제 1 시스템 객체인 'sysschobjs'에서 관리하고 있으며, 각 테이블에 속하는 컬럼에 대한 정보는 상기 제 2 시스템 객체인 'syscolpars'에서 관리한다. 여기서, 상기 'sysschobjs'의 상기 제 1 객체 식별 번호는 34이며, 상기 'syscolpars'의 상기 제 2 객체 식별 번호는 41일 수 있다.
도 3은 본 발명의 일 실시예에 따른 테이블 정보를 포함하는 'sysschobis' 페이지를 도시한 도면으로서, 상기 시스템 객체 'sysschobjs' 관련 페이지 내의 레코드일 수 있다.
보다 구체적으로, 각각의 페이지 헤더 내에서 'Version' 필드 값이 01이고, 'Page Type' 필드 값이 01이며, 'Object ID' 필드 값이 34인 페이지를 찾음으로써, 상기 시스템 객체 'sysschobjs'와 관련된 페이지를 찾을 수 있다. 여기서, 상기 필드 값이 01인 경우는 데이터 페이지임을 의미할 수 있다. 또한, 각 테이블에 대한 정보는 도 3과 같이 'sysschobjs' 페이지 내에서 레코드 형태로 관리되고, 페이지의 마지막에 존재하는 레코드 오프셋 배열을 참조함으로써 각 레코드를 확인할 수 있다. 상기 각 레코드는 하나의 객체와 관련된 정보들을 포함하고 있으며, 객체 식별 번호와 객체의 타입, 객체 이름 등의 정보를 포함한다. 이 중에서 사용자 정의 테이블과 관련된 레코드를 구분하고, 이로부터 테이블 관련 정보를 획득할 수 있다.
도 4는 본 발명의 일 실시예에 따른 컬럼 정보를 포함하는 'syscolpars' 페이지를 도시한 도면으로서, 상기 시스템 객체 'syscoplars' 관련 페이지 내의 레코드일 수 있다. 여기서, 상기 테이블 관련 정보는 시그니처(31), 테이블 오브젝트 ID(32), 컬럼 수(33), 및 컬럼 이름(34)일 수 있다.
보다 구체적으로, 각각의 페이지 헤더 내에서 'Version' 필드 값이 01이고, 'Page Type' 필드 값이 01이며, 'Object ID' 필드 값이 41인 페이지를 찾음으로써, 상기 시스템 객체 'syscolpars'와 관련된 페이지를 찾을 수 있다. 여기서, 상기 필드 값이 01인 경우는 데이터 페이지임을 의미할 수 있고, 데이터베이스 내에 존재하는 모든 테이블의 컬럼 정보가 'syscolpars' 페이지 내에서 레코드 형태로 관리되고 있으며, 페이지의 마지막에 존재하는 레코드 오프셋 배열을 참조함으로써 각 레코드를 확인할 수 있다. 상기 각 레코드는 하나의 컬럼과 관련된 정보들을 포함하고 있으며, 컬럼이 속한 객체의 객체 식별 번호와 컬럼의 타입, 컬럼 이름 등의 정보를 포함한다. 상기 획득한 각 테이블의 객체 식별 번호를 확인한 뒤, 해당 객체 식별 번호를 포함하고 있는 레코드를 구분하고, 이로부터 정보를 추출함으로써 각 테이블의 컬럼 정보를 획득할 수 있다. 여기서, 상기 테이블의 컬럼 정보는 시그니처(41), 컬럼 길이(42), 테이블 오브젝트 ID(43), 컬럼 순서(44), 컬럼 이름(45), 및 자료형(46)일 수 있다. 또한, 자료형(46)에 대한 값은 이하의 표 1과 같을 수 있다.
표 1
자료형
타입 값 타입 값
bigint 0x7F7F binary 0xADAD
bit 0x6868 char 0xAFAF
date 0x2828 datetime 0x3D3D
datetime2 0x2A2A datetimeoffset 0x2B2B
decimal 0x6A6A float 0x3E3E
geography 0x82F0 geometry 0x81F0
hierachyid 0x80F0 image 0x2222
int 0x3838 money 0x3C3C
nchar 0xEFEF ntext 0x6363
numeric 0x6C6C nvarchar 0xE7E7
nvarchar(MAX) 0xE7E7 real 0x3B3B
smalldatetime 0x3A3A smallint 0x3434
smallmoney 0x7A7A sql_variant 0x6262
text 0x2323 time 0x2929
이제 다시 도 1로 돌아가 S120 단계 이후를 설명하도록 한다.
S130 단계에서, 상기 데이터 복원 장치가 상기 데이터 파일의 페이지 내 비 할당 영역을 식별한다. 여기서, 상기 비 할당 영역은 상기 데이터 파일의 페이지 내 페이지 헤더, 레코드, 레코드 오프셋 배열 부분을 제외한 나머지 부분일 수 있다.
보다 구체적으로, S110 단계에서 입력된 데이터 파일은 페이지 단위로 구성되며, 상기 데이터 파일 내에는 여러 가지 종류의 페이지가 존재할 수 있다. 여기서, 데이터 페이지는 이하에서 도 5를 통해 보다 구체적으로 설명하도록 한다.
도 5a는 본 발명의 일 실시예에 따른 페이지 구조를 도시한 도면이다.
보다 구체적으로, 마이크로소프트 SQL 서버 데이터베이스에서 최소 입출력 단위는 '페이지(page)' 이며, 하나의 객체에는 1개 이상의 페이지가 할당되며, 페이지 크기는 사용자 정의에 따라 달라질 수 있으나 기본으로 설정되는 크기는 8192 바이트일 수 있다. 각 페이지는 페이지 헤더(Page Header)(51), 레코드(Data Row)(52), 레코드 오프셋 배열(Row offset array)(53)로 구성될 수 있다. 여기서, 페이지 헤더(51) 부분에서는 해당 페이지에 대한 기본 정보인 페이지 종류, 페이지 내 레코드의 개수 등을 포함할 수 있다. 또한, 레코드 영역(52) 부분에는 실제 데이터가 포함되어 있으며, 레코드 오프셋 배열을 통해 각 레코드의 시작 부분을 참조할 수 있다. 마지막으로, 레코드 오프셋(53)은 각각의 레코드의 시작 위치에 대한 정보를 담고 있는 2 바이트 단위의 배열이고, 페이지의 가장 마지막 부분부터 역순으로 저장되며, 각각의 레코드를 가리키는데 할당되는 오프셋 공간은 2 바이트일 수 있다. 따라서, 상기 오프셋 공간은 2 바이트 단위의 배열이므로 2 바이트의 데이터로 오프셋을 가르킬 수 있다.
또한, 페이지 헤더(51)의 구조는 도 5b와 같이 표현할 수 있고, 페이지 헤더 구조는 60 바이트의 공간이 할당될 수 있으며, 페이지 내에 존재하는 레코드의 개수는 페이지 헤더의 'SlotCnt' 필드(54)에서 확인할 수 있다. 여기서 상기 페이지 헤더(51)는 실제로는 96 바이트이고, 96 바이트 중 60 바이트는 의미 있는 정보를 포함하며, 나머지 36 바이트는 대부분 0x00으로 구성된다.
상기와 같이, 페이지는 페이지 헤더(51), 레코드 영역(52), 레코드 오프셋(53) 부분으로 구분될 수 있다. 또한, 비 할당 영역(55)은 레코드 영역(52)에 존재할 수 있다. 즉, 레코드 영역(52)에 포함된 헤더와 레코드 사이, 레코드와 레코드 사이, 레코드와 레코드 오프셋 사이에 각각 비 할당 영역(55)이 존재할 수 있다. 예를 들어, 도 5c에서 네모 박스부분은 0xF:2060과 0xF:2146부분이 레코드 오프셋(53)에서 가리키는 레코드의 첫 시작 위치이며, 0xF:2146의 레코드 길이는 32바이트이므로, 0xF:2080 ~ 0xF:2145 까지가 레코드 오프셋(53)에서 가리키지 않는 비할당 영역(55) 즉 레코드와 레코드 사이에 존재하는 비할당 영역일 수 있다.
이제 다시 도 1로 돌아가 S130 단계 이후를 설명하도록 한다.
S140 단계에서, 상기 데이터 복원 장치가 상기 비 할당 영역에서 상기 스키마 정보를 이용하여 삭제된 레코드를 추출한다.
보다 구체적으로, 마이크로소프트 SQL 서버 데이터베이스에서는 하나의 레코드를 삭제할 경우, 삭제된 레코드의 실제 데이터 부분은 비 할당 영역에 그대로 존재하며, 해당 부분을 가르키고 있는 레코드 오프셋 부분이 0으로 변경될 수 있다.
도 6은 본 발명의 일 실시예에 따른 레코드 삭제에 따른 레코드 오프셋의 변화를 도시한 도면으로서, 레코드 삭제 전 레코드 오프셋(61)이 레코드 삭제 후 레코드 오프셋(62)으로 변경된 것을 알 수 있다.
따라서, 레코드 삭제로 인해 변경된 레코드 오프셋을 참조하여 S130 단계에서 식별된 비 할당 영역에서 레코드를 분석하고, 분석된 레코드로부터 테이블 정보를 추출하여 추출된 테이블 정보와 S120 단계에서 획득한 스키마 정보에 포함된 테이블 정보를 비교함으로써, 테이블의 구조가 동일할 경우 삭제된 해당 레코드를 추출할 수 있다.
한편, 도 7a 및 도 7b는 int_table 삭제에 따라 'sysschobjs' 페이지의 변화를 도시한 도면으로서, 도 7a에서는 int_table 삭제에 따른 레코드의 변화를 표시하였고, 도 7b에서는 int_table 삭제에 따른 레코드 오프셋 배열의 변화를 표시하였다. 따라서, 테이블이 삭제될 경우 'sysschobjs' 페이지에서 레코드와 레코드 오프셋 배열 부분이 변경되는 것을 알 수 있다.
이제 다시 도 1로 돌아가 S140 단계 이후를 설명하도록 한다.
S150 단계에서, 상기 데이터 복원 장치가 상기 삭제된 레코드에 대하여 레코드의 길이 값을 이용하여 검증함으로써, 검증된 레코드를 복구한다.
보다 구체적으로, 상기 레코드의 종류는 도 8과 같이 레코드 내에 고정적인 길이를 가지는 컬럼들로만 구성된 고정 길이 레코드 구조(81)와 레코드 내에 가변적인 길이를 가지는 컬럼을 포함하는 가변 길이 레코드 구조(82)로 두 가지로 나눌 수 있다. 따라서, 테이블의 컬럼에 따라 고정 길이 레코드 구조(81) 혹은 가변 길이 레코드 구조(82)가 비할당 영역에 있는지 여부를 검증하기 위해서 레코드 내 처음 1바이트에 상태 비트 값과 0x3 위치에서 가리키고 있는 곳의 컬럼 수가 복구하고자 하는 테이블의 컬럼 개수와 동일한지 비교한다. 가변길이 컬럼이 존재하는 경우 가변길이 컬럼 수를 검증하고, 레코드 내에 존재하는 각 데이터의 길이 정보들을 토대로 레코드의 전체 길이를 계산 후 해당 레코드의 길이 값이 테이블 정보에서 획득한 컬럼 개수와 컬럼 정보에서 획득한 컬럼 길이 값과 동일 한가 여부를 검증함으로써, 유효한 레코드를 구분한다.
이후, S150 단계를 통해 식별된 비 할당 영역에서 추출된 레코드의 길이를 계산하여 상기 계산 결과 추출된 레코드가 정상 구조를 가지는 레코드일 경우 해당 레코드의 마지막과 비 할당 영역의 마지막 사이에 추가적인 레코드가 존재하는지 검색함으로써, 추가적인 레코드가 존재할 경우 상기 추가적인 레코드에 대하여 S150 단계를 통해 레코드 형태 여부를 검증하는 과정을 반복할 수 있다.
한편, 도 1의 데이터 복원 방법은 이하에서 도 9a와 같이 또 다른 흐름도로서 표현할 수 있다.
도 9a는 본 발명의 일 실시예에 따른 도 1의 데이터 복원 방법을 도시한 또 다른 흐름도이다. 보다 구체적으로, S910 단계에서, Microsoft SQL Server를 효율적으로 관리하기 위해 필요한 정보를 담고있는 시스템 데이터 베이스인 Master 데이터베이스로부터 현재 연결되어 있는 DB와 연결이 해제되거나 삭제된 DB에 대한 정보를 획득할 수 있다.
S920 단계에서, S910 단계에서 획득한 정보 중 연결이 해제된 DB나 삭제된 DB가 존재하는지 확인함으로써, 존재할 경우 S930 단계로 진행하고 존재하지 않을 경우 S950 단계로 진행할 수 있다.
S930 단계에서, S910 단계에서 획득한 정보 중 경로정보를 검색하여 연결이 해제되거나 삭제된 DB의 MDF파일이 존재하는지 확인함으로써, 존재할 경우 S950 단계로 진행하며 존재하지 않을 경우 S940 단계로 진행할 수 있다.
S940 단계에서, 시스템을 대상으로 MDF 파일을 카빙할 수 있다. 여기서, 상기 시스템은 DBMS 시스템이며, 상기 카빙이란 데이터영역을 스캔하여 복구하는 방법을 말한다. 일반적으로 메타데이터를 통해 파일을 복구하는 복원 과정과는 달리 다른 데이터와는 구별되는 특징적인 구조와 시그니처를 이용하여 복원하는 방법일 수 있다.
S950 단계에서, 상기 MDF 파일 내 이름 정보와 마스터로부터 획득한 정보를 비교함으로써 상기 입력된 MDF 파일에 대하여 검증작업을 진행할 수 있다.
S960 단계에서, S950 단계에서 검증된 MDF 파일에 대하여 각각의 DB별로 복구 과정을 진행함으로써, 삭제된 데이터를 복원할 수 있다. 여기서, S960 단계는 이하에서 도 9b를 통해 보다 구체적으로 설명하도록 한다.
도 9b는 본 발명의 일 실시예에 따른 도 9a의 S960 단계를 보다 구체적으로 도시한 흐름도로서, 앞서 기술한 도 1의 각 과정에 대응하는 구성을 포함한다. 따라서, 여기서는 설명의 중복을 피하기 위해 각 과정의 그 기능을 약술하도록 한다.
보다 구체적으로, 확장자명 MDF인 데이터 파일을 입력받아 테이블 정보를 획득할 수 있다. 여기서, 상기 데이터 파일에 포함된 'sysschobjs' 페이지를 검색하여 테이블 정보를 수집하고, 'syscolpars' 페이지를 검색하여 상기 테이블에 대한 컬럼 정보를 수집할 수 있다.
이후, 상기 데이터 파일의 페이지를 반복적으로 탐색한다. 보다 구체적으로, 상기 MDF파일은 페이지 단위로 구성되어 있다. 따라서, 시작 페이지인 1 페이지부터 파일의 끝에 존재하는 마지막 페이지까지 1페이지 단위로 건너뛰어 데이터 페이지를 반복적으로 탐색할 수 있다. 여기서, 네모 박스 친 공간(91)은 반복 루틴으로서, Page 1부터 PAGE_NUM(마지막 페이지 수)만큼 네모박스(91) 안에 있는 작업들을 PAGE_NUM 만큼 반복하여 수행할 수 있다. 이 부분을 프로그래밍 언어에서 반복 루틴 표현 방식인 for(i=1 ; i < page_num ; i= i+1)로 표현할 수 있다.
이후, 페이지 헤더의 필드 값을 통해 데이터 페이지인지 여부를 조회함으로써, 데이터 페이지 여부를 검사할 수 있다. 이후, 레코드 오프셋 배열을 수집하여 상기 레코드 오프셋 배열에 대하여 오름차순 정렬할 수 있다. 이후, 데이터 페이지에 접근 한 후 데이터 페이지에 존재하는 레코드 에 접근한다. Row Offset Array의 1번째부터 Row Offset Array 에 존재하는 Offset 개수만큼 다음 과정을 반복 수행한다. 여기서, T는 임의의 T이며 Row Offset Array 배열에 대해 배열에 존재하는 레코드 수만큼 네모박스(92) 안의 내부 루틴을 반복 수행할 수 있으며, 'T=1. OFFSET_NUM, 1'표현할 수 있다.
이후, Row Offset Array 배열에 존재하는 값을 주소로 사용하여 임의의 레코드 첫 위치에 접근할 수 있다. 레코드가 속하는 테이블의 컬럼의 개수와 데이터 타입에 따라 레코드 길이가 다를 수 있으므로 레코드의 내부 정보를 통해서 해당 레코드의 길이를 계산할 수 있다. 이때, 계산된 레코드의 길이를 P라 할 수 있다.
이후, 임의의 변수 T는 1부터 Row Offset Array 총 개수만큼 다음과정을 반복 한다. 이때, T가 5라고 가정하면 Row Offset Array에 존재하는 5번째 값을 이용하여 레코드의 첫 위치에 접근한 후 해당 레코드의 길이를 계산한다. 레코드의 길이는 P에 저장할 수 있다. (단, T = 5 이며 OFFSET(T) = 5번째 레코드가 존재하는 주소 값) 그리고 T를 1증가 시키고 Row Offset Array에 존재하는 6번째 값을 통해 다음 레코드(OFFSET(T+1))에 접근한다. 이때, OFFSET(T+1)의 값과 OFFSET(T)+P의 값이 동일한지 판단하여 동일할 경우 바로 다음 레코드를 의미하고 OFFSET(T+1) > OFFSET(T)+P인 경우에는 OFFSET(T+1)와 OFFSET(T) 사이에 비할당 영역이 존재한다고 판단할 수 있다. 여기서, != 는 프로그래밍언어에서 사용하는 비교 연산자이며 수학기호에서의 ≠ 와 동일한 의미일 수 있다.
이후, 현재 레코드(OFFSET(T)+P+1)의 위치에서 다음 오프셋(OFFSET(T+1)-1)까지 존재하는 레코드를 추출하여 삭제된 레코드 길이를 계산하고, 계산된 레코드의 길이를 검증함으로써, 검증된 레코드를 출력함으로써, 삭제된 레코드를 복구 할 수 있다.
도 10은 본 발명의 일 실시예들이 채택하고 있는 데이터 복원 장치를 도시한 블럭도로서, 데이터 복원 장치(100)는 앞서 기술한 도 1의 각 과정에 대응하는 구성을 포함한다. 따라서, 여기서는 설명의 중복을 피하기 위해 시스템의 세부구성을 중심으로 그 기능을 약술하도록 한다.
입력부(101)는 데이터베이스로부터 데이터 파일을 입력받는다.
처리부(102)는 상기 데이터 파일로부터 스키마 정보를 도출하고, 상기 데이터 파일의 페이지 내 비 할당 영역을 식별한다.
추출부(103)는 상기 비 할당 영역에서 상기 스키마 정보를 이용하여 삭제된 레코드를 추출하되, 상기 삭제된 레코드에 대하여 레코드의 길이 값을 이용하여 검증함으로써, 검증된 레코드를 복구한다.
또한, 처리부(102)는, 상기 데이터 파일에서 제 1 식별 번호를 이용하여 테이블에 대한 정보를 포함하는 제 1 시스템 객체를 도출하고, 상기 데이터 파일에서 제 2 식별 번호를 이용하여 테이블에 속하는 컬럼에 대한 정보를 포함하는 제 2 시스템 객체를 도출하며, 상기 도출된 제 1 시스템 객체 및 제 2 시스템 객체로부터 상기 스키마 정보를 도출할 수 있다.
또한, 상기 제 1 시스템 객체는, 레코드 오프셋 배열에 따라 각각의 레코드를 구분할 수 있으며, 상기 각각의 레코드는 레코드별로 객체 식별 번호, 객체의 타입, 및 객체 이름을 포함할 수 있다.
또한, 상기 제 2 시스템 객체는, 레코드 오프셋 배열에 따라 각각의 레코드를 구분할 수 있고, 상기 각각의 레코드는 레코드별로 하나의 컬럼과 관련된 정보를 포함하며, 상기 하나의 컬럼과 관련된 정보는 컬럼이 속한 객체의 객체 식별 번호, 컬럼의 타입, 및 컬럼 이름을 포함할 수 있다.
또한, 상기 비 할당 영역은 상기 데이터 파일의 페이지 내 페이지 헤더, 레코드, 레코드 오프셋 배열 부분을 제외한 나머지 부분일 수 있다.
또한, 상기 레코드가 삭제될 경우 상기 스키마 정보에 포함된 레코드 오프셋 중 상기 삭제된 레코드 오프셋의 주소를 포함하는 레코드 오프셋이 0으로 변경될 수 있다.
한편, 본 발명의 데이터 복원 방법과 관련하여 데이터 복원 도구를 제작하고, 마이크로소프트 SQL 서버 데이터베이스에서 삭제된 모든 데이터를 고려하여 복원을 시행하였다. 여기서, 데이터 복원 도구에 대한 입력은 mdf 확장자를 가지는 마이크로소프트 SQL 서버 데이터베이스의 데이터 파일이며, 해당 데이터 파일로부터 스키마 정보를 획득하고 획득한 정보를 토대로 복원을 시도하며, 삭제된 모든 레코드를 추출하도록 시행할 경우 삭제된 레코드들이 정상적으로 추출되는 것을 확인할 수 있었다.
한편, 본 발명은 실시예들은 컴퓨터로 읽을 수 있는 기록 매체에 컴퓨터가 읽을 수 있는 코드로 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 기록 매체는 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록 장치를 포함한다.
컴퓨터가 읽을 수 있는 기록 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등을 포함한다. 또한, 컴퓨터가 읽을 수 있는 기록 매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산 방식으로 컴퓨터가 읽을 수 있는 코드가 저장되고 실행될 수 있다. 그리고 본 발명을 구현하기 위한 기능적인(functional) 프로그램, 코드 및 코드 세그먼트들은 본 발명이 속하는 기술 분야의 프로그래머들에 의하여 용이하게 추론될 수 있다.
이상에서 본 발명에 대하여 그 다양한 실시예들을 중심으로 살펴보았다. 본 발명에 속하는 기술 분야에서 통상의 지식을 가진 자는 본 발명이 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 변형된 형태로 구현될 수 있음을 이해할 수 있을 것이다. 그러므로 개시된 실시예들은 한정적인 관점이 아니라 설명적인 관점에서 고려되어야 한다. 본 발명의 범위는 전술한 설명이 아니라 특허청구범위에 나타나 있으며, 그와 동등한 범위 내에 있는 모든 차이점은 본 발명에 포함된 것으로 해석되어야 할 것이다.
상기된 본 발명에 따르면, 데이터 파일로부터 스키마 정보를 획득하고 삭제된 레코드가 존재하는 비 할당 데이터 영역에 접근하여 스키마 정보를 이용하여 삭제된 레코드를 복구함으로써, 회사 정책이나 데이터베이스 설정으로 인한 트랜잭션 로그가 삭제시 상기 트랜잭션 로그가 없는 경우에도 데이터를 복구할 수 있는 효과가 있다. 나아가, 디지털 포렌식 관점에서 용의자가 고의적으로 데이터를 삭제하였을 경우 해당 데이터를 복구하여 증거 및 삭제 행위 입증이 가능한 효과가 있다.

Claims (14)

  1. 데이터 복원 장치가 데이터베이스로부터 데이터 파일을 입력받는 단계;
    상기 데이터 복원 장치가 상기 데이터 파일로부터 스키마 정보를 도출하는 단계;
    상기 데이터 복원 장치가 상기 데이터 파일의 페이지 내 비 할당 영역을 식별하는 단계;
    상기 데이터 복원 장치가 상기 비 할당 영역에서 상기 스키마 정보를 이용하여 삭제된 레코드를 추출하는 단계; 및
    상기 데이터 복원 장치가 상기 삭제된 레코드에 대하여 레코드의 길이 값을 이용하여 검증함으로써, 검증된 레코드를 복구하는 단계를 포함하는 데이터 복원 방법.
  2. 제 1 항에 있어서,
    상기 데이터베이스는 마이크로소프트 SQL 서버 데이터베이스인 것을 특징으로 하는 데이터 복원 방법.
  3. 제 1 항에 있어서,
    상기 데이터 파일은 확장자명 MDF이고, 사용자가 생성한 객체의 테이블 정보, 컬럼정보, 및 사용자 데이터를 저장하는 것을 특징으로 하는 데이터 복원 방법.
  4. 제 1 항에 있어서,
    상기 스키마 정보를 도출하는 단계는,
    상기 데이터 복원 장치가 상기 데이터 파일에서 제 1 식별 번호를 이용하여 테이블에 대한 정보를 포함하는 제 1 시스템 객체를 도출하는 단계;
    상기 데이터 복원 장치가 상기 데이터 파일에서 제 2 식별 번호를 이용하여 테이블에 속하는 컬럼에 대한 정보를 포함하는 제 2 시스템 객체를 도출하는 단계; 및
    상기 데이터 복원 장치가 상기 도출된 제 1 시스템 객체 및 제 2 시스템 객체로부터 상기 스키마 정보를 도출하는 단계를 포함하는 데이터 복원 방법.
  5. 제 4 항에 있어서,
    상기 제 1 시스템 객체는,
    레코드 오프셋 배열에 따라 각각의 레코드를 구분할 수 있으며, 상기 각각의 레코드는 레코드별로 객체 식별 번호, 객체의 타입, 및 객체 이름을 포함하는 것을 특징으로 하는 데이터 복원 방법.
  6. 제 4 항에 있어서,
    상기 제 2 시스템 객체는,
    레코드 오프셋 배열에 따라 각각의 레코드를 구분할 수 있고, 상기 각각의 레코드는 레코드별로 하나의 컬럼과 관련된 정보를 포함하며, 상기 하나의 컬럼과 관련된 정보는 컬럼이 속한 객체의 객체 식별 번호, 컬럼의 타입, 및 컬럼 이름을 포함하는 것을 특징으로 하는 데이터 복원 방법.
  7. 제 1 항에 있어서,
    상기 비 할당 영역은 상기 데이터 파일의 페이지 내 페이지 헤더, 레코드, 레코드 오프셋 배열 부분을 제외한 나머지 부분인 것을 특징으로 하는 데이터 복원 방법.
  8. 제 1 항에 있어서,
    상기 레코드가 삭제될 경우 상기 스키마 정보에 포함된 레코드 오프셋 중 상기 삭제된 레코드 오프셋의 주소를 포함하는 레코드 오프셋이 0으로 변경되는 것을 특징으로 하는 데이터 복원 방법.
  9. 데이터베이스로부터 데이터 파일을 입력받는 입력부;
    상기 데이터 파일로부터 스키마 정보를 도출하고, 상기 데이터 파일의 페이지 내 비 할당 영역을 식별하는 처리부; 및
    상기 비 할당 영역에서 상기 스키마 정보를 이용하여 삭제된 레코드를 추출하는 추출부를 포함하되,
    상기 삭제된 레코드에 대하여 레코드의 길이 값을 이용하여 검증함으로써, 검증된 레코드를 복구하는 것을 특징으로 하는 데이터 복원 장치.
  10. 제 9 항에 있어서,
    상기 처리부는,
    상기 데이터 파일에서 제 1 식별 번호를 이용하여 테이블에 대한 정보를 포함하는 제 1 시스템 객체를 도출하고, 상기 데이터 파일에서 제 2 식별 번호를 이용하여 테이블에 속하는 컬럼에 대한 정보를 포함하는 제 2 시스템 객체를 도출하며, 상기 도출된 제 1 시스템 객체 및 제 2 시스템 객체로부터 상기 스키마 정보를 도출하는 것을 특징으로 하는 데이터 복원 장치.
  11. 제 10 항에 있어서,
    상기 제 1 시스템 객체는,
    레코드 오프셋 배열에 따라 각각의 레코드를 구분할 수 있으며, 상기 각각의 레코드는 레코드별로 객체 식별 번호, 객체의 타입, 및 객체 이름을 포함하는 것을 특징으로 하는 데이터 복원 장치.
  12. 제 10 항에 있어서,
    상기 제 2 시스템 객체는,
    레코드 오프셋 배열에 따라 각각의 레코드를 구분할 수 있고, 상기 각각의 레코드는 레코드별로 하나의 컬럼과 관련된 정보를 포함하며, 상기 하나의 컬럼과 관련된 정보는 컬럼이 속한 객체의 객체 식별 번호, 컬럼의 타입, 및 컬럼 이름을 포함하는 것을 특징으로 하는 데이터 복원 장치.
  13. 제 9 항에 있어서,
    상기 비 할당 영역은 상기 데이터 파일의 페이지 내 페이지 헤더, 레코드, 레코드 오프셋 배열 부분을 제외한 나머지 부분인 것을 특징으로 하는 데이터 복원 장치.
  14. 제 9 항에 있어서,
    상기 레코드가 삭제될 경우 상기 스키마 정보에 포함된 레코드 오프셋 중 상기 삭제된 레코드 오프셋의 주소를 포함하는 레코드 오프셋이 0으로 변경되는 것을 특징으로 하는 데이터 복원 장치.
PCT/KR2015/004032 2014-04-23 2015-04-23 마이크로소프트 sql 서버 데이터베이스에서 데이터를 복원하는 방법 및 장치 WO2015163696A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR20140048690 2014-04-23
KR10-2014-0048690 2014-04-23

Publications (1)

Publication Number Publication Date
WO2015163696A1 true WO2015163696A1 (ko) 2015-10-29

Family

ID=54332785

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2015/004032 WO2015163696A1 (ko) 2014-04-23 2015-04-23 마이크로소프트 sql 서버 데이터베이스에서 데이터를 복원하는 방법 및 장치

Country Status (1)

Country Link
WO (1) WO2015163696A1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111104259A (zh) * 2019-12-23 2020-05-05 厦门市美亚柏科信息股份有限公司 一种数据库恢复方法、装置及存储介质
EP3798842A4 (en) * 2018-12-10 2022-04-13 Xiamen Meiya Pico Information Co., Ltd METHOD AND SYSTEM FOR RECOVERING DELETED DATABASE RECORDS

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20120097293A (ko) * 2011-02-24 2012-09-03 고려대학교 산학협력단 데이터베이스 복원 방법 및 장치
KR20140000369A (ko) * 2012-06-22 2014-01-03 고려대학교 산학협력단 문서파일의 포렌식 분석 방법 및 시스템

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20120097293A (ko) * 2011-02-24 2012-09-03 고려대학교 산학협력단 데이터베이스 복원 방법 및 장치
KR20140000369A (ko) * 2012-06-22 2014-01-03 고려대학교 산학협력단 문서파일의 포렌식 분석 방법 및 시스템

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
CHOI, JONG - HYUN ET AL.: "The Method of Recovery for Deleted Record in Oracle Database", JOURNAL OF THE KOREA INSTITUTE OF INFORMATION SECURITY & CRYPTOLOGY(JKIISC, vol. 23, no. 5, 2013, XP055232790 *
PARK, SOO YOUNG: "A Research for Record Recovery Method in Database", MASTER'S THESIS OF KOREA UNIVERSITY, December 2013 (2013-12-01) *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3798842A4 (en) * 2018-12-10 2022-04-13 Xiamen Meiya Pico Information Co., Ltd METHOD AND SYSTEM FOR RECOVERING DELETED DATABASE RECORDS
CN111104259A (zh) * 2019-12-23 2020-05-05 厦门市美亚柏科信息股份有限公司 一种数据库恢复方法、装置及存储介质
CN111104259B (zh) * 2019-12-23 2022-08-12 厦门市美亚柏科信息股份有限公司 一种数据库恢复方法、装置及存储介质

Similar Documents

Publication Publication Date Title
US7966287B2 (en) Apparatus, system, and method for dynamic database driven document synchronization
US8442951B1 (en) Processing archive content based on hierarchical classification levels
CN109144968B (zh) 一种数据分布管理系统
WO2010123168A1 (ko) 데이터베이스 관리 방법 및 시스템
US9158804B1 (en) Method and system for efficient file-based backups by reverse mapping changed sectors/blocks on an NTFS volume to files
WO2014189190A1 (ko) 데이터 부재 태깅 기반의 정보 검색 시스템 및 방법
KR101547466B1 (ko) 오라클 데이터베이스에서 데이터를 복원하는 방법 및 장치
WO2013136418A1 (ja) ログ管理計算機、及びログ管理方法
WO2017146337A1 (ko) 데이터베이스의 아카이빙 방법 및 장치, 아카이빙된 데이터베이스의 검색 방법 및 장치
KR101085735B1 (ko) 기초 테이블로부터 삭제된 행을 식별하는 컴퓨터 구현 방법, 기초 테이블에 삽입된 행을 식별하는 컴퓨터 구현 방법, 삭제된 행의 식별 시스템, 삽입된 행의 식별 시스템, 및 컴퓨터 판독가능 저장 매체
US8099397B2 (en) Apparatus, system, and method for improved portable document format (“PDF”) document archiving
WO2015182835A1 (ko) 데이터 처리 시스템 및 방법
US20120179990A1 (en) Capturing and Visualizing Data Lineage in Content Management System
WO2021107211A1 (ko) 인메모리 데이터베이스 기반의 시계열 데이터 관리시스템
CN102750204A (zh) 一种恢复数据的方法、装置
WO2015163696A1 (ko) 마이크로소프트 sql 서버 데이터베이스에서 데이터를 복원하는 방법 및 장치
CN105740103A (zh) 一种基于日志的ntfs删除文件恢复方法和装置
WO2020055141A1 (en) Method and device for detecting duplicate content
WO2017069337A1 (ko) 인메모리 데이터베이스를 이용한 데이터 관리 방법 및 그 장치
Meshram et al. Digital forensic analysis of hard disk for evidence collection
US10474534B1 (en) Method and system for efficient file indexing by reverse mapping changed sectors/blocks on an NTFS volume to files
WO2023113158A1 (ko) 범죄 행위자 프로파일링 방법, 이를 수행하는 장치 및 컴퓨터 프로그램
WO2015163697A1 (ko) Db2 데이터베이스에서 데이터를 복원하는 방법 및 장치
WO2019074155A1 (ko) 데이터베이스 간의 실시간 통합 복제 시스템
KR20120097293A (ko) 데이터베이스 복원 방법 및 장치

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: 15782384

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: 15782384

Country of ref document: EP

Kind code of ref document: A1