EP1715425A2 - Méthode et système pour la préservation de l'accès à un système en cas de sinistre - Google Patents

Méthode et système pour la préservation de l'accès à un système en cas de sinistre Download PDF

Info

Publication number
EP1715425A2
EP1715425A2 EP05021972A EP05021972A EP1715425A2 EP 1715425 A2 EP1715425 A2 EP 1715425A2 EP 05021972 A EP05021972 A EP 05021972A EP 05021972 A EP05021972 A EP 05021972A EP 1715425 A2 EP1715425 A2 EP 1715425A2
Authority
EP
European Patent Office
Prior art keywords
replica
primary
filestore
database
data
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.)
Withdrawn
Application number
EP05021972A
Other languages
German (de)
English (en)
Other versions
EP1715425A3 (fr
Inventor
Rajesh Kapur
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
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
Priority claimed from CA002504070A external-priority patent/CA2504070C/fr
Priority claimed from CA002506100A external-priority patent/CA2506100C/fr
Priority claimed from GB0515579A external-priority patent/GB2445584A/en
Priority claimed from GB0518016A external-priority patent/GB2445368A/en
Application filed by Individual filed Critical Individual
Publication of EP1715425A2 publication Critical patent/EP1715425A2/fr
Publication of EP1715425A3 publication Critical patent/EP1715425A3/fr
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2097—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements maintaining the standby controller/processing unit updated
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2094—Redundant storage or storage space
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1658—Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare unit
    • G06F11/1662—Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare unit the resynchronized component or unit being a persistent storage device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1675—Temporal synchronisation or re-synchronisation of redundant processing components
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2089—Redundant storage control functionality

Definitions

  • the present invention relates to a method for preserving access to document data within a primary system by using a backup replica system in a offsite location.
  • the secondary replica system can be used.
  • the present invention relates to a method and system for producing a "real time" backup of a primary document management system able to recover from any eventuality.
  • Document management software is used in many large companies to provide a streamlined and efficient way of managing day to day business activities.
  • the purpose of the software is to help companies keep track of large volumes of documents in an organised way.
  • the documents can be easily stored, found and retrieved.
  • version control is an issue of particular importance.
  • Version control is an aspect of most document management systems that enables different people to have shared access to a document. In addition to having shared access, the individuals have a right to individually modify the shared documents.
  • document management software may be used in a large engineering company that has many versions of the same part. When a part is ordered by a client, the correct part version needs to be found by the engineering company.
  • Document management systems typically include a system database associated with a filestore.
  • the filestore stores actual document data while the system database stores reference information that points to the document within the filestore.
  • the system database also typically stores supplementary document information regarding each document.
  • DocumentumTM is an example of a document management system that comprises three different layers (or technologies) located on top of a server based operating system such as UnixTM or Windows 2000TM, a system database, and a filestore.
  • the Documentum layers are located on top of a database and the layers serve Documentum client interfaces.
  • the reference information i.e. the information pointing to the physical document data
  • the supplementary document information i.e. the attributes of the types of the documents stored
  • the actual physical data is stored in a filestore on either the server, a Storage Area Network (SAN) or filer pointed to by the server.
  • SAN Storage Area Network
  • a present method of overcoming this problem involves writing a new system and migrating data across. With this method there is a risk associated to the current system.
  • a more recent method involves creating a replicated server by storing document data within a system in a separate location. The document data is stored in a system filestore associated with a system database. The replicated server is built, upgraded and then the data is switched or toggled to the enable the new replica to become the production system. The data is copied from the filestore using a full backup/restore function on one night of the week to the secondary backup store. The following night, the primary production server is shutdown and incremental backup and database export is taken and these are applied to the secondary server. This step ensures the plurality of the data for the point in time when a switch could be made. While this is an improvement on the previous known methods, there is still the problem that the two systems are only synchronised for a brief moment in time.
  • a method for preserving access of a system in case of disaster having a primary filestore and a primary system database comprising the steps of:
  • Another aspect of the present invention there is provided a method for preserving access of a system in case of disaster having a primary filestore and a primary system database, the method comprising the steps of:
  • Another aspect of the present invention there is provided a method for preserving access of a system in case of disaster having a primary filestore and a primary system database, the method comprising the steps of:
  • Another aspect of the present invention provides a system for preserving access of a system in case of disaster having a primary filestore and a primary system database, comprising: a replica system having a replica filestore and a replica system database; a second empty replica filestore for recording all changes to the primary filestore; at least one set of three database triggers on each primary system table save those that uniquely identify the primary system on the network fabric for catching recording and transferring, reference data to the replica system database which has been inserted deleted and or been updated in the primary system table.
  • at least one set of access preservation tables for storing access preservation data; at least one set of transaction tables one being placed on the replica, and primary system for storing all transactions, and reference data on the basis of earliest recorded time.
  • the invention has the advantages that it provides full and consistent recovery in case of total or partial loss of the primary system although a few transactions may be lost due to latency (time taken to transfer files across) i.e.. In other words there is little or no loss of data in this scenario as the replica system filestore can be rolled forward from the last snapshot to literally the last transaction. The user can chose partial recovery to rollback to the last backup if he so wishes. Also that in the case of corruption to the primary, system, the replica system can be consistently rolled back to any point in time at which the company deems, this is independent of snapshot time or backups although the company can decide to do this if they so wish. Another advantage is it requires the least amount of maintenance , disk space and constituent parts for the speedy recovery it provides. Finally, that users on the primary system are unaffected by this system.
  • the primary system is operably connected to a network fabric.
  • the replica system is operably connected to a network fabric.
  • the primary system has information loaded onto it, and is based on the first server.
  • the replica system has information loaded onto it, and is based on a second server.
  • the first system and the replica system are configured to allow client computers operably connected to the network fabric to locate information owned by the first system and information owned by the replica system.
  • the replica system replicates the first system.
  • the replica system is located in an off-site location.
  • the system comprises a Document Management System residing on a server (Unix or Windows 2000 server) comprising of a filestore storing the actual document data and a system database storing reference information pointing to the documents within a filestore, supplementary information on the document, together with system specific information.
  • the database of the replica system is configured to mirror the information in that of the first system's system database less a portion of the data which allows the replica system to be uniquely identified on the network fabric.
  • the filestore containing documents is connected to the network fabric.
  • the filestore is based on a Storage Area Network (SAN) or Filer connected to the network fabric.
  • SAN Storage Area Network
  • the primary system's server can be connected to the filestore.
  • the replica system's server can be connected to a separate filestore the replica filestore in this case would need to have incremental backups from the first filestore to be continuously applied to it throughout, perhaps at hourly intervals.
  • the incremental backup is done every hour and automatically applied to the replica filestore.
  • the replica system has a secondary initially empty filestore to store files copied over from the primary filestore that have changed, as.
  • the primary and replica system databases are linked through the network fabric.
  • the method comprises of using Oracle Database software linking primary and secondary system databases on the network fabric by means of an Oracle database link command.
  • this link between primary and replica system databases is by a means of a SQL server linked server command.
  • both the primary and replica systems databases have the required access permissions to access, modify, insert or delete data in each other and are accessible to each other across the network fabric.
  • the method comprises document data being added to the filestore and reference data modified within system tables in the primary system database, and wherein the recording step comprises the step of recording reference data from all primary system tables, save those holding system specific data.
  • the primary system in response to a insert, update, delete command, inserts, updates, deletes reference data to each of the system tables affected for each particular transaction.
  • the recording step comprises recording the reference data using at least one database trigger.
  • the recording step comprises recording the reference data using three database triggers associated with each system table, excepting those tables, which allow the first system to be uniquely identified on the network fabric.
  • the method comprises adding a first database trigger associated with recording the changes after an insert command on each table, adding a second database trigger associated with recording the changes after an update command on each table and adding a third database trigger associated with recording the changes after a delete command on each database table, excepting those tables that define the primary system on the network fabric.
  • the method comprises performing identical changes, to that which can occur after an insert, update, delete command on each primary system database table and are recorded within the respective database trigger pertaining to that particular transaction to the substantially identical replica system database table, by means of the salient SQL command contained within the three triggers on each of the primary database tables, the transfer, and application of the identical SQL command made possible only by the primary and replica database systems being linked through a database link on the network fabric.
  • the three triggers on each table in the primary database record the changes on update, insert, delete to access-preservation tables and a single transaction table for all changes on all tables.
  • the transfer is carried out within a second set of database triggers attached to the access preservation tables so as not to affect performance.
  • the single transaction table contains the group: the type of transaction (i.e. update, delete, Insert), the system table on which the transaction is performed, the primary key of the table, and a Date-timestamp.
  • the recording step comprises using at least one access-preservation table.
  • the recording step comprises using a set of three access preservation tables for each primary system table to be mirrored in the replica's database tables.
  • the method additionally comprises using a database stored procedure to apply the changes and transactions recorded in the access-preservation tables and transaction table, to the replica system should the database link be severed for any reason including that of maintenance to the secondary system on a time based input parameter, once the database link is restored and user input is halted temporarily.
  • a set of database procedures can be used in contingency the database link is severed for any reason.
  • the system can then be returned to the said automated transfer using the SQL command within the triggers on each table, with the user input recommenced.
  • the access-preservation tables and the combined transaction table are stored on the replica server in case of failure of the first.
  • the set comprises a first access-preservation table to receive reference data recorded from the insert transaction on each system table, a second access-preservation table to receive reference data recorded from the update transaction on each system table, and a third access preservation table to receive reference data recorded from the delete transaction on each system table.
  • the method comprises input restriction until the primary and replica system databases are re-synchronised.
  • the method comprises the contingency of applying the changes through at least a single database procedure using the combination transaction table and access-preservation tables, in order to resynchronise the primary and replica systems once the database link is restored.
  • the method comprises using Documentum as the Document Management System for both the primary and replica system.
  • the method comprises of using the primary system for the user community to store their documents.
  • the method comprises of using the secondary system as a disaster recovery system.
  • the method comprises document data being added to the filestore and reference data modified within Documentum system tables in the primary Oracle system database, and wherein the recording step comprises the step of recording reference data from all primary system tables, save those holding server specific data.
  • the replica system can be also used as a disaster recovery system in case of failure of the primary system.
  • the replica system in the case of disaster the replica system can be used, the system is synchronised by applying the latest incremental filestore backup from the primary filestore and applying it to the replica filestore and accessing the transaction table and access-preservation tables, and second replica filestore to either back out or insert transactions to the point of recovery for the replica system database and replica system filestore.
  • the system comprises a Documentum document management system, and wherein the method is carried out additionally it is appreciated that the secondary server be used as a "Standby" this is comprehended by this invention but is not the primary purpose.
  • the recording, inserting, updating, deleting and providing steps and standard database constructs are executed by the execution of Oracle database software code.
  • the recording, inserting, updating, deleting and providing steps and standard database constructs are executed by the execution of SQL Server database software code.
  • the primary system 1 is made up of a system database 9 including a number of system tables 10 and a filestore 11.
  • the actual physical data i.e. the document data files themselves are stored in the filestore 11, in this case shown as a storage area network (SAN).
  • Reference information about the data stored in the filestore i.e. information pointing to the physical document data and supplementary document information, i.e. the attributes of the types of documents stored are stored in the system database 9.
  • the data sent to the system tables 10 is in the form of Metadata.
  • Metadata contains information sufficient to enable a system to identify each file stored in the filestore 11 sufficiently to enable authorised personnel to retrieve, protect and carry out the disposition of the files in the filestore 11. This information may include items such as: place of origin, file code/identification, key words for retrieval etc.
  • metadata is generated. The metadata is used to update information in the system tables 10 corresponding to the file held in the system filestore 11. Therefore, if a document is added, updated or deleted, the metadata will provide information of this to the system database of the primary system 9 to track the changes to be made to the filestore, and any metadata associated with those files.
  • the system database shown comprises a system table 10 (which represents one table of many that is inserted, updated or deleted from not being one which uniquely identifies the primary system on the network from the replica system), access preservation tables 13, procedure 16, sets of database triggers 14 each containing three database triggers, e.g. update, delete and insert, and a transaction table 15.
  • the replica system comprises a replica filestore 17, a secondary empty filestore 18, to receive copies of files inserted , deleted and updated. Again these are shown to be on a storage area network (SAN), coupled to a replica system 3.
  • the filestore 11, of the primary system 9 and the replica filestores 17,18 are connected, optionally across a network fabric, a link that enables a backup to be made of the contents of the filestore 11 of the primary system to the replica filestore 17 at periodic intervals say hourly.
  • the backup may be taken as a snapshot or on an incremental basis.
  • By backup (incremental, snapshot) a copy of the primary system filestore 11 at that point in time, is taken and this can be applied to the primary filestore 17 of the replica system.
  • the primary and replica system databases are connected by a database link 25.
  • the replica system database 19 comprises system table 20 which corresponds to the system table 10 of the primary (and merely represents one system table of many, access preservation tables 21, procedures 22 to carry out the asynchronous updates and or rollback required by using the information contained within the access preservation tables 21, and the transaction table 23 together with up to date file information, contained within the secondary filestore 18.
  • the document management system splits the data entered by the user down into its constituent parts including the data files and metadata relating to the files.
  • the metadata part that performs the functions of update, insert or delete of the data, is written to tables 10 within the database (known as the system tables) by either adding a new row or updating data in an existing row within the system tables or deleting a row from the tables.
  • the system tables 10, 20 are originally added by the document management system to the database of choice on installation.
  • the physical data is added to or deleted from the filestore 11.
  • each trigger 14 on each table 10 , 13 is code that automatically executes to make exactly the same change in the replica system database 19 as when the change is made in the system database 9 of the primary system, preferably, however, the code to transfer the changes is placed in a second set of triggers 14a which fire when the first set 14 record the transaction to the access preservation tables. This is in response to any operation formed on a file in the primary system. In other words, to insert, update or delete a document.
  • the corresponding tables 20 in the replica system 3 are thus updated as and when the tables 10 in the primary system are updated, save those that uniquely identify the primary and secondary system upon the network.
  • the triggers contain code within them to fill preferably, three access preservation tables 13 on the primary database 9, for each system table 10.
  • a row is added to the access preservation table for inserts for that table.
  • the access preservation table for delete for that table is added to.
  • On update preferably, but is not necessarily all three access preservation tables for that table are updated in this case there will be no update trigger on the update preservation table as a update is covered by a delete and insert transaction.
  • Each row has a recorded timestamp against it. The procedure will also be activated thus providing an up-to-date record of the content of the corresponding files in the second filestore of the replica.
  • each transaction carried out on any of the required system tables is also stored within a database transaction table 15.
  • the data stored in the database transaction table includes, but is not limited to, the following information: the date-timestamp (that was recorded in the access preservation table); the type of transaction; the system table 10 in which the change occurred; and the primary key of the row being updated.
  • the same triggers also update the same information in the set of preservation tables 21 and transaction table 23 in the replica database system 24.
  • the information stored in the transaction tables of the primary and replica database 15 and 23 may be used to update metadata, and copy files to be stored in the replica filestore 18.
  • any changes that took place to documents in the primary filestore since the breakage of link are transfered to the replica filestore 18, and should be saved in the transaction table of the replica database system by means of procedures 22. Therefore, the data stored in the transaction table of the, primary, and replica systems may be used to update the documents saved in the replica filestore to a time just prior to breakage of the link.
  • the replica system can be synchronised to remain fully up-to-date with the primary system. Snapshots would take care of any updates to the primary replica filestore 17 that were necessary.
  • the replica system shown should ideally be housed in an offsite location so that any damage caused to the primary system resulting from electrical or other problems would not affect the backup on the replica system.
  • the first command of the above trigger shows the SQL command and the "after delete row" trigger on the primary database automatically deletes the row in the secondary table.
  • the insert statement is necessary in case the link is severed which can happen from time to time in case of maintenance, or in case of failure.
  • Oracle code shows this can be used in order to preserve the data in access preservation tables and the transaction table.
  • the access- preservation tables and transaction table are used instead at a later point by database procedures that can run in the transactions in sequence to the replica database.
  • the triggers and procedures being "Enabled" in the secondary.
  • a "after row insert” and "after row update” is preferably used, meaning that the data values of the row that have been, inserted or updated are actually captured notice the new values inserted are always used. On a “before insert "old values do not exist. This ensures that all salient and/or relevant information is captured.
  • An oracle database procedure or stored procedure is a piece of oracle execution code and carries out logical instructions.
  • An oracle trigger is a piece of application code that can be applied to an oracle "table" (a storage unit like a filling cabinet) which when particular transactions are carried out on the table it fires automatically to execute the code within it.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
EP05021972A 2005-04-14 2005-10-08 Méthode et système pour la préservation de l'accès à un système en cas de sinistre Withdrawn EP1715425A3 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CA002504070A CA2504070C (fr) 2005-04-14 2005-04-14 Methode de conservation d'acces a des documents supprimes et ecrases
CA002506100A CA2506100C (fr) 2005-04-14 2005-05-04 Methode de preservation de l'acces a un systeme en cas de sinistre
GB0515579A GB2445584A (en) 2005-05-04 2005-07-28 Database backup and retrieval using transaction records and a replicated data store
GB0518016A GB2445368A (en) 2005-04-14 2005-09-05 A method and system for preserving access to a system in case of a disaster allowing transaction rollback

Publications (2)

Publication Number Publication Date
EP1715425A2 true EP1715425A2 (fr) 2006-10-25
EP1715425A3 EP1715425A3 (fr) 2010-03-24

Family

ID=36950263

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05021972A Withdrawn EP1715425A3 (fr) 2005-04-14 2005-10-08 Méthode et système pour la préservation de l'accès à un système en cas de sinistre

Country Status (1)

Country Link
EP (1) EP1715425A3 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101989305A (zh) * 2010-11-09 2011-03-23 福州星网视易信息系统有限公司 数据增量备份方法和系统
CN110110024A (zh) * 2019-04-29 2019-08-09 东南大学 一种大容量vct文件导入空间数据库方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6330573B1 (en) * 1998-08-31 2001-12-11 Xerox Corporation Maintaining document identity across hierarchy and non-hierarchy file systems

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6330573B1 (en) * 1998-08-31 2001-12-11 Xerox Corporation Maintaining document identity across hierarchy and non-hierarchy file systems

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Enabling Business Continuity for Enterprise Content Infrastructure" INTERNET CITATION, [Online] 2003, pages 1-13, XP008116063 Retrieved from the Internet: URL:http://www.emc.com/collateral/software /white-papers/h3351-biz-continu ity-wp.pdf> [retrieved on 2009-12-09] *
DOMINIC J DELMOLINO: "Strategies and Techniques for Using Oracle7 Replication" INTERNET CITATION, [Online] XP002267343 Retrieved from the Internet: URL:http://www.indiana.edu/dbateam/resources/tips/ddelmoli.pdf> [retrieved on 2004-01-16] *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101989305A (zh) * 2010-11-09 2011-03-23 福州星网视易信息系统有限公司 数据增量备份方法和系统
CN110110024A (zh) * 2019-04-29 2019-08-09 东南大学 一种大容量vct文件导入空间数据库方法
CN110110024B (zh) * 2019-04-29 2021-12-17 东南大学 一种大容量vct文件导入空间数据库方法

Also Published As

Publication number Publication date
EP1715425A3 (fr) 2010-03-24

Similar Documents

Publication Publication Date Title
US20060235905A1 (en) Method and system for preserving real-time access to a system in case of a disaster
US11740974B2 (en) Restoring a database using a fully hydrated backup
US10891067B2 (en) Fast migration of metadata
US8712970B1 (en) Recovering a database to any point-in-time in the past with guaranteed data consistency
EP1635244B1 (fr) Procédé et système pour créer une routine d'archivage pour protèger des données dans un système de protection de données
US20060129618A1 (en) Method and a computer system for synchronising backups of objects and of meta data about the objects
EP3796174B1 (fr) Restauration d'une base de données à l'aide d'une sauvegarde entièrement hydratée
US8712966B1 (en) Backup and recovery of distributed storage areas
US20060235904A1 (en) Method for preserving access to system in case of disaster
KR20060050607A (ko) 데이터 보호 시스템에서 강건하고 관리하기 쉬운 데이터보호 애플리케이션들을 생성하기 위한 아키텍쳐 모델을만드는 방법, 시스템 및 장치
EP2382543B1 (fr) Établissement de l'origine du cycle de vie de données d'application granulaires à partir d'une copie de sauvegarde unique
US20060253500A1 (en) Method for validating system changes by use of a replicated system as a system testbed
EP1715425A2 (fr) Méthode et système pour la préservation de l'accès à un système en cas de sinistre
CA2531714C (fr) Methode et systeme pour proteger l'acces a un systeme en cas de sinistre
GB2445368A (en) A method and system for preserving access to a system in case of a disaster allowing transaction rollback
CA2506100C (fr) Methode de preservation de l'acces a un systeme en cas de sinistre
US20210064482A1 (en) Filesystem Operation Bookmarking for Any Point in Time Replication
WO2006108260A1 (fr) Procede de validation de mises a jour du systeme au moyen d'un systeme replique tel qu'un banc d'essai du systeme
GB2445584A (en) Database backup and retrieval using transaction records and a replicated data store
EP1713008B1 (fr) Procédé et système pour la préservation d'accès aux documents effacés ou écrasés au moyen d'une boîte à ordures du système
CA2545532A1 (fr) Methode et systeme permettant de fournir un systeme lie a un reseau pour la reprise apres sinistre et l'essai de mise a niveau
GB2445370A (en) Method for preserving access to deleted and overwritten documents by means of a system recycle bin
Kuhn et al. Chapter 16 User-Managed Backup and Recovery
Beldalker et al. Oracle Database Backup and Recovery Basics 10g Release 1 (10.1) Part No. B10735-01 Copyright© 2003 Oracle Corporation. All rights reserved. Primary Author: Antonio Romero Contributing Author: Lance Ashdown
Dewson Database Backup, Recovery, and Maintenance

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20051104

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK YU

PUAL Search report despatched

Free format text: ORIGINAL CODE: 0009013

AK Designated contracting states

Kind code of ref document: A3

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK YU

RIC1 Information provided on ipc code assigned before grant

Ipc: G06F 11/14 20060101ALI20100218BHEP

Ipc: G06F 12/00 20060101ALI20100218BHEP

Ipc: G06F 17/30 20060101AFI20100218BHEP

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20100504