DE69728178T2 - Vorrichtung und verfahren zur fernen datenrückgewinnung - Google Patents

Vorrichtung und verfahren zur fernen datenrückgewinnung Download PDF

Info

Publication number
DE69728178T2
DE69728178T2 DE69728178T DE69728178T DE69728178T2 DE 69728178 T2 DE69728178 T2 DE 69728178T2 DE 69728178 T DE69728178 T DE 69728178T DE 69728178 T DE69728178 T DE 69728178T DE 69728178 T2 DE69728178 T2 DE 69728178T2
Authority
DE
Germany
Prior art keywords
computer
data recovery
local
data
remote
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.)
Expired - Lifetime
Application number
DE69728178T
Other languages
English (en)
Other versions
DE69728178D1 (de
Inventor
Scott Gary STEVENS
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.)
KLDiscovery Ontrack LLC
Original Assignee
Ontrack Data International Inc
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 US08/877,125 external-priority patent/US6145088A/en
Application filed by Ontrack Data International Inc filed Critical Ontrack Data International Inc
Application granted granted Critical
Publication of DE69728178D1 publication Critical patent/DE69728178D1/de
Publication of DE69728178T2 publication Critical patent/DE69728178T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/2294—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing by remote test
    • 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/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • 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/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0727—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a storage system, e.g. in a DASD or network based storage system
    • 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/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0748—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a remote unit communicating with a single-box computer node experiencing an error/fault

Description

  • Technisches Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft im Allgemeinen die Wiederherstellung von Informationen von Computerdatenspeichereinrichtungen und/oder -medien und im Besonderen die Wiederherstellung von Informationen, welche von der normalen Betriebsumgebung nicht erreichbar sind, sowie ein Verfahren für das Ermöglichen einer Ferndiagnose und Fernberichtigung solch eines Datenverlustes.
  • Hintergrund der Erfindung
  • Der wahre Wert eines Computersystems für einen Nutzer ist nicht beschränkt auf die tatsächlichen Kosten der Hardware und Softwarekomponenten, welche dieses System umfasst, sondern beinhaltet auch den Wert der Daten, die innerhalb dieses Systems vertreten sind. Es ist in der Tat ziemlich üblich, dass Buchhaltungsdaten, geistiges Eigentum, Design und Herstellungsinformationen und/oder andere Datensätze, welche auf einem Computersystem im persönlichen und geschäftlichen Gebrauch gespeichert sind, letztendlich einen Wert besitzen, welcher den Wert der Computerausrüstung selbst bei Weitem überschreitet.
  • Der Verlust der Möglichkeit, auf Daten auf einer Computerspeichereinrichtung, wie beispielsweise einem Diskettenlaufwerk, zuzugreifen, kann häufig als ein Ergebnis eines Bedienerfehlers, einer fehlerhaften Software, vorübergehenden elektrischen Ereignissen, Sabotagehandlungen, oder elektrischer/mechanischer Fehler auftreten. Obwohl die Daten von der normalen Betriebsumgebung nicht zugänglich sind, existieren in vielen Fällen die Daten selbst immer noch auf dem Speichermedium und können durch Manipulieren der Datenstrukturen auf dem Medium zugänglich gemacht werden, welche das/die Dateisystem(e) repräsentieren, die von der Betriebsumgebung eingesetzt werden. Eine solche Manipulation von Datenstruk turen auf dem Medium wird am zuverlässigsten durch geschulte Techniker durchgeführt, die mit hoch spezialisierten Softwarewerkzeugen ausgerüstet sind.
  • Es ist gelegentlich der Fall, dass die Unerreichbarkeit von Daten der Grund für signifikante Kosten und/oder für ein verlorenes Geschäft sein kann, dies manchmal in einem katastrophalen Ausmaß. Während manche Datenformen Kandidaten für die Wiederherstellung sein können, können die Kosten für diese Wiederherstellung von trivial bis unerschwinglich teuer reichen. Zusätzlich benötigt die Datenwiederherstellung eine begrenzte Zeit, während der Geschäftsaspekte notwendigerweise unterbrochen oder behindert sein können, auf Grund einer Abhängigkeit von den unerreichbaren Daten. Er bestehen auch Kategorien von Daten, welche im Allgemeinen in Echtzeit erlangt werden, welche nicht wiederhergestellt werden können, und welche deshalb als unersetzbar betrachtet werden können.
  • Traditionelle Redundanzmechanismen, wie beispielsweise Off-line Backup, zielen darauf ab, eine Befreiung von Datenverlustsituationen bereitzustellen. Die Wiederherstellung von einem Off-line Backup kann jedoch zeitintensiv sein und kann Daten bereitstellen, welche bezüglich der Daten, welche durch Datenwiederherstellungsverfahren potentiell verfügbar sein könnten, alt sind. Deshalb können selbst Datenverluste, welche theoretisch von einem Off-line Backup wiederherstellbar sind, als potentielle Datenwiederherstellungskandidaten betrachtet werden.
  • Kommerzielle Datenwiederherstellungsdienstgeschäfte adressieren diese Angelegenheiten mit verschiedenen Kategorien von Diensten. Diese beinhalten typischerweise sowohl On-site- als auch Off-site-Dienste. Off-side-Datenwiederherstellungsdienste, in welchen das Medium oder die Einrichtung, die die unzugänglichen Daten beinhalten, von einem Datenwiederherstellungstechniker bei einer Serviceeinrichtung bearbeitet wird, erfordert das physikalische Entfernen des Mediums oder der Einrichtung von den Kundenräumlichkeiten und den Transport zu der Serviceeinrichtung. Dies kann eine signifikante Ausfallzeit verursachen auf Grund der Verzögerungen, welche durch den Transport hervorgerufen werden. Es bestehen auch Situationen, bei denen die Daten sensibel sind und wo entsprechende Sicherheitsüberlegungen es diktieren, dass die Entfernung von Daten von dem Ort nicht ratsam ist. Viele Situationen sind sensibel selbst gegenüber den Verzögerungen, welche durch die Verwendung von über-Nacht-Transporten hervorgerufen werden. On-site-Datenwiederherstellungsservices, in welchen der Datenwiederherstellungstechniker und spezialisierte Ausrüstung zu den Kunden räumlichkeiten reisen und die Dienste lokal durchführen, können die Ausfallzeit reduzieren, jedoch zu den hinzukommenden Kosten des Transports des Technikers und der notwendigen Ausrüstung zu und von der Kundenstätte.
  • Es gibt Fernsteuerungsverfahren, welche es einem Computer erlauben, an einer Kommunikationsleitung über eine Kommunikationshardware angebunden zu werden, so dass er von einem Bediener an einen zweiten Computer, der ebenfalls an die Kommunikationsleitung über eine Kommunikationshardware angebunden ist, gesteuert wird. Solche Hardwarekonfigurationen sind typisch in Personalcomputern, und eine solche Fernsteuerungssoftware ist bereits für gewöhnliche Personalcomputerbetriebssytsteme verfügbar. Beispiele solcher Fernsteuerungsprogramme beinhalten PCanywhere, Remote 2, Carbon Copy, etc. Ein Nachteil dieses Ansatzes ist, dass der wiederherzustellende Computer mit einem Betriebssystem laufen muss, welches die Fernsteuerungssoftware unterstützt. Deshalb ist dieser Ansatz nutzlos, wenn das Betriebssystem die Fernsteuerung nicht unterstützt.
  • Das Dokument WO-A-95 19595 offenbart ein System für das entfernte Ansteuern und Betreiben eines Personalcomputers. Es offenbart eine Software, die auf einem entfernten Personalcomputer installiert ist, um den Aufbau von Kommunikation zwischen einem entfernten Personalcomputer und einem Hostcomputer zu erlauben. Es erlaubt ferner, dass ein Kaltstart des Hostcomputers entfernt von dem entfernten Personalcomputer ausgelöst wird.
  • Ein System und ein Verfahren für das zuverlässige Erlauben der Fernwiederherstellung von Computerspeichermedien und Einrichtungen durch einen entfernten Techniker ist deshalb ein akutes Bedürfnis der Technik. Der konventionelle Stand der Technik erfordert es, dass die Computerspeichermedien oder Einrichtungen von einem Techniker betrieben werden, entweder am Ort des Kunden oder der Anlage des Technikers. Das Leistungsverhalten von Datenwiederherstellungsservices von außen bzw. entfernt, über eine Telefonverbindung, wurde erfolgreich eingesetzt, um die Schwächen der On-site- und Off-site-Wiederherstellung zu überwinden, erfordert jedoch, dass der Zielcomputer in der Lage ist, ein Betriebssystem zu laden, welches die Fernsteuerungssoftware unterstützt und einen Zugriff auf die Daten erlaubt, welche wiederhergestellt werden sollen. Leider können die Umstände, die zu einem Datenverlust führen, häufig auch verursachen, dass das normale Betriebssystem instabil oder unbrauchbar wird. Folglich besteht ein spezielles Bedürfnis in der Technik nach einem Ver fahren für die Bereitstellung von Ferndatenwiederherstellungsmöglichkeiten, selbst wenn das normale Betriebssystem nicht zwingend ladbar oder verlässlich ist.
  • Zusammenfassung der Erfindung
  • Die vorliegende Erfindung löst diese Probleme und stellt ein Verfahren wie in Anspruch 1 definiert, sowie eine Vorrichtung, wie in Anspruch 14 definiert, für die Ferndatenwiederherstellung (Remote Data Recovery, RDR) von Computerdatenspeichervorrichtungen und/oder -medien bereit, welche von der normalen Betriebsumgebung und für ein Verfahren der Ferndiagnose und Fernberichtigung von Datenverlust unerreichbar sind.
  • Es ist ein Gegenstand der vorliegenden Erfindung, Mittel bereitzustellen, um Ferndatenwiederherstellungshandlungen zu ermöglichen, einschließend, jedoch nicht beschränkt auf solche Situationen, bei denen das normale Betriebssystem nicht lauffähig ist.
  • Eine Ausführungsform der Erfindung betrifft ein Verfahren für das entfernte Wiederherstellen aus der Ferne von Daten von einem Speichermedium in einem lokalen Computer, der ein normales Betriebssystem besitzt, wie in Anspruch 1 definiert.
  • Weitere Verbesserungen werden durch die Unteransprüche bereitgestellt.
  • In einer Ausführungsform werden die Prinzipien der vorliegenden Erfindung durch Implementieren eines boot-fähigen Datenwiederherstellungsbetriebssystems erreicht, welches eine ausreichende Funktionalität besitzt, um eine Kommunikation über eine Kommunikationshardware an den entfernten Techniker zu erlauben. Der entfernte Techniker ist ferner mit einer spezialisierten Fernsteuerungssoftware ausgerüstet, welche eine Kommunikation mit dem Computer, auf dem das boot-fähige Datenwiederherstellungsbetriebssystem läuft, über die Kommunikationshardware erlaubt. Wenn sich der Computer, der sich unter Wiederherstellung befindet, und der entfernte Computer in Kommunikation befinden, können Datenwiederherstellungshandlungen auf dem Computer, der sich unter Wiederherstellung befindet, unter vollständiger Steuerung bzw. Kontrolle des entfernten Technikers ablaufen.
  • In einer bevorzugten Ausführungsform ist das Ferndatenwiederherstellungsbetriebssystem ausreichend klein, um direkt von dessen eigener Vertriebsdiskette zu laufen, was es erlaubt, dass Datenwiederherstellungsoperationen in der Abwesenheit des normalen boot-fähigen Betriebssystems ablaufen. Dieses ist imstande, eine Datenwiederherstellungsdienstsoftware von entweder derselben Distributionsdiskette oder von einer vergleichsweise ausgedehnten Sammlung solcher Software des entfernten Technikers, über die Kommunikationshardware zu laden.
  • In der bevorzugten Ausführungsform präsentiert, nach dem Laden, das boot-fähige Ferndatenwiederherstellungsbetriebssystem eine beschränkte Anzahl an Wahlmöglichkeiten an den lokalen Benutzer, was es dem Benutzer ermöglicht, Informationen bezüglich der Natur der Bedürfnisse der Datenwiederherstellung des Benutzers und der persönlichen Daten des Benutzers einzugeben. Nachdem diese Information eingegeben wurde, kann der lokale Benutzer seine Absicht bestätigen, dass das Betriebssystem Kontakt mit dem entfernten Techniker über die angebundene Kommunikationshardware ausbauen lässt. Dieser Kontakt kann die Datenwiederherstellungsoperation unmittelbar einleiten, oder, alternativ die Anfrage derart einreihen, dass die Datenwiederherstellungsoperation zu einer solchen Zeit abläuft, wenn der Datenwiederherstellungstechniker Zeit gehabt hat, die Anfrage durchzusehen und sich auf die Datenwiederherstellung vorzubereiten. Nachdem die Datenwiederherstellungsoperation gestartet ist, wird die gesamte Kontrolle des lokalen Computers für den Ferndatenwiederherstellungstechniker frei gegeben. Der Techniker ist dann in der Lage, den lokalen Computer zu betreiben als ob der Techniker direkt davor plaziert wäre, wobei er Zugriff auf die gesamte Datentwiederherstellungsdienstsoftware hat, welche sowohl am Ort des Technikers verfügbar ist, als auch jede beliebige, welche optional sich auf der Datenwiederherstellungsbetriebssystemdiskette befinden kann.
  • Im Gebrauch kann die Datenwiederherstellung mittels einer Ausführungsform der vorliegenden Erfindung durch Booten oder Laden des boot-fähigen Ferndatenwiederherstellungsbetriebsprogramms in den Speicher des lokalen Computers des Benutzers ablaufen. Das Ferndatenwiederherstellungsbetriebsprogramm ermittelt dann die spezifische Hardwarekonfiguration des lokalen Computers des Benutzers. Das Ferndatenwiederherstellungsbetriebsprogramm kann dann den Benutzer nach seinem/ihrem Namen, Adresse, Telefonnummer, etc., abfragen. Es kann ferner den Benutzer nach einer Erklärung der Datenwiederherstellungssitu ation befragen. Das Ferndatenwiederherstellungsbetriebsprogramm baut dann eine anfängliche Telefonverbindung über die Kommunikationshardware mit dem Ferndatenwiederherstellungscomputer auf, und lädt die Informationen, die von dem Benutzer in den obigen Schritten eingegeben wurden, herunter. Wenn es die Zeit erlaubt, übernimmt der Techniker an dem Ferndatenwiederherstellungscomputer dann die Steuerung des Computers des Benutzers über die Fernverbindung und startet das Ferndatenwiederherstellungsverfahren. Andernfalls kann eine spätere Zeit für das Ferndatenwiederherstellungsverfahren beschlossen werden. Folglich wird die Fernverbindung unterbrochen und dann zu der abgesprochenen Zeit wiederaufgebaut, woraufhin die Ferndatenwiederherstellung startet.
  • Diese und vielzählige andere Vorteile und Merkmale der Neuheit, welche die Erfindung charakterisieren, werden mit Sorgfalt in den hieran angehängten Ansprüchen herausgestellt und bilden einen Teil hiervon. Für ein besseres Verständnis der Erfindung jedoch, deren Vorteile und der Merkmale, die während derer Verwendung erhalten werden, sollte Bezug genommen werden auf die beigefügten Zeichnungen und das Beschreibungsmaterial, welche einen weiteren Teil hiervon bilden, und in welchen eine bevorzugte Ausführungsform der Erfindung verdeutlicht und beschrieben ist.
  • Kurze Beschreibung der Zeichnungen
  • In den Zeichnungen, in denen entsprechende Referenznummern, die im Allgemeinen entsprechende Teile überall in den verschiedenen Ansichten bezeichnen, gilt:
  • 1 ist ein Blockdiagramm einer Ausführungsform einer Vorrichtung gemäß den Prinzipien der vorliegenden Erfindung;
  • 2 ist ein Blockdiagramm einer weiteren Ausführungsform einer Vorrichtung gemäß den Prinzipien der vorliegenden Erfindung;
  • 3 ist ein Software-Hierarchiediagramm der lokalen Umgebung einer Ausführungsform der vorliegenden Erfindung;
  • 4 ist ein Flussdiagramm einer lokalen RDR-Anwendung einer Ausführungsform der vorliegenden Erfindung;
  • 5 ist ein Flussdiagramm eines Teiles der lokalen RDR-Anwendung einer Ausführungsform der vorliegenden Erfindung, welche den ferngesteuerten Betrieb des lokalen Computers ermöglicht;
  • 6 ist ein Flussdiagramm eines Teils der lokalen RDR-Anwendung einer Ausführungsform der vorliegenden Erfindung, welche die Kommunikationskanalereignisse handhabt;
  • 7 ist ein Flussdiagramm eines Teils der lokalen RDR-Anwendung einer Ausführungsform der vorliegenden Erfindung, welche diverse eingehende Datenpakete handhabt;
  • 8 ist ein Flussdiagramm eines Teils der lokalen RDR-Anwendung einer Ausführungsform der vorliegenden Erfindung, welche ausgehende Kommunikationsdatenpackete sendet;
  • 9 ist ein Flussdiagramm eines Teils der lokalen RDR-Anwendung einer Ausführungsform der vorliegenden Erfindung, welche das native Betriebssystem-API abfängt und verarbeitet für Datei-Erstellungs-/Öffnungs-/Schließ-Funktionen;
  • 10 ist ein Flussdiagramm eines Teils der lokalen RDR-Anwendung einer Ausführungsform der vorliegenden Erfindung, welche das native Betriebssystem-API abfängt und verarbeitet für Bildschirm-Lese- und Schreibfunktionen;
  • 12 ist ein Flussdiagramm einer RDR-Kommunikationsserveranwendung einer Ausführungsform der vorliegenden Erfindung;
  • 13 ist ein Flussdiagramm eines Teils der RDR-Kommunikationsserveranwendung einer Ausführungsform der vorliegenden Erfindung, welche die Verhandlung der Rückrufzeit mit dem Benutzer des lokalen Computers ermöglicht;
  • 14 ist ein Flussdiagamm eines Teils der RDR-Kommunikationsserveranwendung einer Ausführungsform der vorliegenden Erfindung, welche die Datenwiederherstellungsdiagnoseanwendung auf den lokalen Computer herunterlädt und deren Ausführung veranlasst;
  • 15 ist ein Flussdiagamm eines Teils der RDR-Kommunikationsserveranwendung einer Ausführungsform der vorliegenden Erfindung, welche eine rechtliche Übereinkunft an die Übereinkunftsleseanwendung auf dem lokalen Computer herunterlädt und dessen Ausführung veranlasst;
  • 16 ist ein Flussdiagamm eines Teils der RDR-Kommunikationsserveranwendung einer Ausführungsform der vorliegenden Erfindung, welche eine logische Verbindung zwischen dem lokalen Computer und einer geeigneten RDR-Workstation ausbaut und diese logische Verbindung aufrechterhält;
  • 17 ist ein Flussdiagramm eines Teils der RDR-Kommunikationsserveranwendung einer Ausführungsform der vorliegenden Erfindung, welche Datei-Öffnungs-/Erstellungs-/Schließ-Anfragepakete von dem lokalen Computer handhabt;
  • 18 ist ein Flussdiagramm eines Teils der RDR-Kommunikationsserveranwendung einer Ausführungsform der vorliegenden Erfindung, welche Dateischreib-Anfragedatenpakete von dem lokalen Computer handhabt;
  • 19 ist ein Flussdiagramm eines Teils der RDR-Kommunikationsserveranwendung einer Ausführungsform der vorliegenden Erfindung, welche diverse Anfrage-Datenpakete von dem lokalen Computer handhabt;
  • 20 ist ein Flussdiagamm eines Teils der RDR-Kommunikationsserveranwendung einer Ausführungsform der vorliegenden Erfindung, welche TCP/IP-Nachrichten von dem RDR-Workstation-Computer handhabt;
  • 21 ist ein Flussdiagamm der RDR-Workstation-Hauptanwendung einer Ausführungsform der vorliegenden Erfindung;
  • 22 zeigt Computerbildschirme, die Formulare abbilden, die der Benutzer des lokalen Computers ausfüllen muss, um Informationen bezüglich der Identität des Benutzers und der Natur der gegenwärtigen Datenverlustsituation und des entsprechenden gewünschten Service bereitzustellen;
  • 23 zeigt Computerbildschirme, welche Informationen an die Administratoren der Ferndatenwiederherstellungseinrichtung bereitstellen, um den Kommunikationsserver zu verwalten;
  • 24 zeigt Computerbildschirme, welche es dem Benutzer der Ferndatenwiederherstellungs-Workstation erlauben, die Ausgabe von Programmen des Ferndatenwiederherstellungs-Lokalcomputers zu steuern und zu beobachten, und das Aussehen des tatsächlichen Bildschirms des Ferndatenwiederherstellungs-Lokalcomputers zu steuern und zu kontrollieren;
  • 25 beinhaltet beschreibende Zeichnungen von Datenstrukturen, die in einer Ausführungsform der lokalen Ferndatenwiederherstellungsanwendung verwendet werden;
  • 26 beinhaltet beschreibende Zeichnungen weiterer Datenstrukturen, die in einer Ausführungsform der lokalen Ferndatenwiederherstellungsanwendung verwendet werden, sowie beschreibende Zeichnungen von Datenstrukturen, die in einer Ausführungsform der Ferndatenwiederherstellungskonvnunikationsserveranwendung verwendet werden;
  • 27 ist ein Flussdiagramm des IO-logischen Layers innerhalb der lokalen RDR-Anwendung 308, welche die Möglichkeit des „Rückgängigmachen" aller beliebigen Modifikationen, die an der lokalen Datenspeichervorrichtung 26 vorgenommen wurden, implementiert; und
  • 28 ist ein Flussdiagramm einer Anwendung, welche die Protokolldateien manipuliert, um die Aussetzung von Änderungen, das Überlassen der neuen Daten und die potentielle Wiederherstellung der Originaldaten zu ermöglichen.
  • Detaillierte Beschreibung der Erfindung
  • Bezug nehmend nun auf die Zeichnungen, wird eine Ausführungsform einer Vorrichtung und eines Verfahrens für die Fernwiederherstellung von Daten beschrieben. In 1 ist ein Blockdiagramm einer Ausführungsform der vorliegenden Erfindung dargestellt. Ein lokaler Ferndatenwiederherstellungs-(Remote Data Recovering, RDR)Computer 20, für welchen eine Datenwiederherstellungsprozedur benötigt wird, wird dargestellt als eine zentrale Prozessoreinheit (Central Processing Unit, CPU) und einen Speicher 21 (typischerweise auf einer üblichen Systemplatine angeordnet), ein lokales Eingabegerät 22, ein lokales Display 24, ein lokales Speichergerät 26, sowie ein Wechselspeichermediengerät 28 besitzend. Zusätzlich wird der lokale RDR-Computer 20 so gezeigt, dass er eine lokale Kommunikationshardware-Einheit 30 für das Kommunizieren mit anderen Computern, beispielsweise ein Modem oder eine Netzwerkkarte, besitzt. Der lokale RDR-Computer 20 kann jedes beliebige IBM-kompatible System oder ein anderer Typ eines Computersystems sein, welche gewöhnlich von verschiedenen Lieferanten wie Gateway 2000, IBM, Apple, Hewlett Packard, Compaq, etc. vertrieben werden. Im Speziellen kann die Hauptsystemplatine des lokalen RDR-Computers 20 eine Intel-CPU, wie beispielsweise eine 386, 486 oder 586, besitzen oder jeden beliebigen anderen Mikroprozessor zusammen mit einer geeigneten Menge an Arbeitsspeicher (Random Access Memory, RAM). Das lokale Eingabegerät 22 kann jede geeignete An eines Benutzereingabegeräts sein, wie beispielsweise eine Tastatur, eine Maus, ein Pointer, ein berührungssensitiver Bildschirm etc. Mehr als ein Benutzereingabegerät 22 kann anwesend sein. Das lokale Display 24 kann jedes geeignete Displaygerät, wie beispielsweise eine optische Anzeigeeinheit sein. Das lokale Speichergerät 26 kann intern oder extern sein und kann sich unterschiedlicher Technologien bedienen. Das Speichergerät kann eine konventionelle Festplatte, wie beispielsweise eine gemäß der Winchester-Technologie, eine Laserdiskette, eine CD-Rom etc. sein. Das Wechselspeichermediengerät 28 kann ein konventionelles Diskettenlaufwerk oder jedes beliebige andere geeignete Wechselmedienlaufwerk sein. Die lokale Kommunikationshardware-Einheit 30 kann jeder beliebige konventionelle Typ eines Modemgeräts, wie beispielsweise eine Hayes-kompatibles Modem, ein ISDN-Modem, ein wireless Modem sein, oder sie kann alternativ eine konventionelle Lokalnetz-, Fernnetz- oder Internet-(LAN/WAN Internet)Verbindungshardware, wie beispielsweise eine Netzwerkkarte etc. sein.
  • Eine Ausführungsform einer Ferndatenwiederherstellungs-(RDR)Workstation 40 zur Ferndatenwiederherstellung ist in 1 gezeigt, eine CPU und einen zugeordneten Speicher 41, ein Ferneingabegerät 42, ein Ferndisplay 44, ein Fernspeichergerät 46, sowie ein Fernwechselspeichermediengerät 48 besitzend. Die RDR-Workstation 40 ist ferner derart gezeigt, dass sie eine Fernkommunikationshardware-Einheit 50, wie beispielsweise ein Modem oder eine Netzwerkkarte, besitzt. Es wird erkannt werden, dass die RDR-Workstation 40 und deren zugeordnete Komponenten dieselben sein können, wie die für den lokalen RDR-Computer 20 oben beschriebenen. Es wird auch erkannt werden, dass der Hauptkommunikationskanal 35 zwischen dem lokalen RDR-Computer 20 und der RDR-Workstation 40 eine Telefonleitung oder herkömmliche LAN/WAN/Internet-Konnektivitäts-Kommunikationskanäle sein können.
  • In 2 ist noch eine weitere Ausführungsform eines Systems gemäß den Prinzipien der vorliegenden Erfindung gezeigt. In dieser Ausführungsform ist eine Vielzahl von RDR-Workstations 40 durch ein Lokalnetzwerk miteinander verbunden. In der gezeigten Ausführungsform verbindet ein Fileserver 60 die RDR-Workstations 40 mittels eines Netzwerks 62, vorzugsweise eines TCP-IP-Netzwerks, miteinander. Der Fileserver 60 besitzt Daten 64, die auf Netzwerk-freigegebenen Laufwerken 65 gespeichert sind, so dass die Daten von den RDR-Workstations 40 und dem Kommunikationsserver 68 zugänglich sind. Die RDR-Workstations 40 sind imstande, über das TCP-IP-Netzwerk 62 mit dem Kommunikationsserver 68 in solch einer Weise zu kommunizieren, dass der Aufbau einer oder mehrerer logischer Verbindungen zwischen einer ausgewählten RDR-Workstation 40 und einer beliebigen Netzwerkkommunikationshardware-Einheit 69 ermöglicht wird. Die Netzwerkkommunikationshardware-Einheiten 69 können Modems sein, die mit Außentelefonleitungen verbunden sind, oder sie können eine Netzwerkhardware sein, die mit dem LAN/WAN/Internet oder dergleichen verbunden ist. Die Netzwerkhardware-Kommunikationseinheiten 69 kommunizieren mit lokalen RDR-Computern 20 über einen Kommunikations-Switch 70, wie beispielsweise einem PBX. Folglich kann jede beliebige der RDR-Workstations 40 verwendet werden, um Daten von einem lokalen RDR-Computer 20 über den Kommunikationskanal 35 gleichzeitig mit vielen anderen RDR-Workstations 40 wiederherzustellen, die verwendet werden, um Daten von verschiedenen lokalen RDR-Computern wiederherzustellen. Diese Ausführungsform kann verwendet werden, um den Zugriff für jeden beliebigen einer Anzahl von Technikern zu erlauben, um eine Ferndatenwiederherstellung nach dem Wählen einer einzigen Nummer oder nach Verbinden mit einer einzigen Einheit in dem LAN/WAN/Internet bereitzustellen.
  • In der bevorzugten Ausführungsform wird ein Ferndatenwiederherstellungsbetriebssystem an den Besitzer/Käufer des lokalen RDR-Computers 20 auf einem Wechelspeichermedium wie beispielsweise einer Diskette bereitgestellt. Das Programm kann zur Zeit des Computerkaufs erworben werden oder alternativ über Retail-Outlets oder postalische Bestellung zu einem späteren Datum erworben werden. Es kann zusätzlich durch jede beliebige Anzahl elektronischer Verteilmechanismen bereitgestellt werden, einschließlich des BBS-ähnlichen Betriebsmodus („Gastmodus") des Kommunikationsservers 68 und dessen Netzwerkkommunikationshardware-Einheit 69.
  • Die Programme, die von dem Ferndatenwiederherstellungsbetriebsprogramm bereitgestellt werden, beinhalten folglich eine ausreichende Funktionalität, um den Betrieb des lokalen RDR-Computers 20 und die Kommunikation über die lokale Kommunikationshardware-Einheit 30 mit der RDR-Workstation 40 zu erlauben.
  • 3 beschreibt die verschiedenen Software-Komponenten, welche das Ferndatenwiederherstellungsbetriebsprogramm umfassen. Verschiedene Datenwiederherstellungsanwendungsprogramme 300 arbeiten, um die Datenwiederherstellung und/oder Diagnoseverfahren zu bewirken. Solche Programme können funktionale Diagnose-Routinen für Speichergeräte, Speichermedien-Analyseroutinen, Sektor-Editoren, welche in Hexadezimal, ASCII oder anderen Formaten arbeiten, die relevant für das wiederherzustellende Dateisystem sind, Datei-Nicht-Lösch-Routinen und Dateisystemintegritätsprüfungs-/Reparaturroutinen, die relevant für das wiederherzustellende Dateisystem sind, beinhalten. Diese Datenwiederherstellungsanwendungsprogramme 300 korrelieren in allgemeinen Worten mit Routinen, die in den Softwarepaketen NORTON UTILITIES® oder ontrack-ODR-N TM oder DOSUTILS® zu finden sind.
  • Die Datenwiederherstellungsanwendungs(data recovery application, DRA)-Programme 300 lassen sich mit der lokalen RDR-Anwendung 308 verbinden durch einen Satz von Anwendungsprogrammschnittstellen (application program interfaces, API's 310), welche sich direkt mit dem elementaren Eingabe/Ausgabe-Subsystem (basic input/output subsystem, BIOS) 360 und/oder dem Betriebssystem 340 verbinden lassen. Die lokale RDR-Anwendung 308 leitet diese API's effektiv um oder „hakt" („hooks") diese ein, um den Fernsteuerbetrieb des DRA 300 zu erlauben. Zusätzlich bietet die lokale RDR-Anwendung 308 private API's an, welche es „RDR-bewussten" Anwendungen erlauben, direkt mit dem Kommunikationssubsystem 312 sich verbinden zu lassen durch Bereitstellen einer „Durchreiche" („pass-through") zu den „eingehakten" BIOS-Funktionen 316 und den OS-Funktionen 314. Dies ermöglicht es den „RDR-bewussten"-Anwendungen, die Umleitung von Funktionen zu überbrücken, was folglich eine Schnittstelle zum Bediener des lokalen RDR-Computers 20 sowie die Steuerung des Kommunikations-Subsystems ermöglicht. Der Rest der lokalen RDR-Anwendung 308 enthält den Kommunikations-Subsystem-Code 318 und den lokalen RDR-Anwendungscode 320. Ein Flussdiagramm des lokalen RDR-Anwendungscode 320 ist in 4 gezeigt.
  • Die Software-Komponenten eines solchen Systems können ein Datenwiederherstellungs-Betriebssystem (data recovery operating system, DROS) 306 als das lokale RDR-Computerbetriebssystem 340 beinhalten. Das DROS 306 erlaubt es, dass die Ferndatenwiederherstellung stattfindet, wenn das native Betriebssystem des lokalen RDR-Computers nicht funktioniert. Das DROS 306 beinhaltet Routinen, die notwendig sind, die lokale RDR-Anwendung 308 und alle beliebigen gewünschten Datenwiederherstellungs-Anwendungsprogramme 300, die verwendet werden, um den Datenwiederherstellungsprozess durchzuführen, zu unterstützen. Beispiele solch notwendiger Routinen beinhalten Speichermanagement-, Dateisystemzugriff- und -management, Anwendungprogrammlade- und -ausführungs- und Peripherie-Geräte-Steuerungs-Funktionen. Diese Routinen gleichen im Allgemeinen einigen MS-DOS Interrupt 21H-Funktionen. Um es der lokalen RDR-Anwendung 308 zu erlauben, zusätzlich zu allen beliebigen Datenwiederherstellungsanwendungsprogrammen 300 zu laufen, kann das DROS 306 direkt die Rufkonventionen und das Protokoll des nativen Betriebssystem emulieren. Zusätzlich kann eine Bedienerkommando-Interpretationsfunktionalität bereitgestellt werden, welche dem nativen Kommandozeilen-Interpreter ähnelt. Die lokale RDR-Anwendung kann auch unter Benutzung des nativen Betriebssystems als das lokale RDR-Computerbetriebssystem 340 betrieben werden.
  • Im Beispiel der IBM-kompatiblen Personalcomputer wird die Schnittstelle zu der darunter liegenden Hardware 380 über eine übliche Schnittstelle erreicht, die von dem elementaren Eingabe/Ausgabe-Subsystem oder BIOS 360 bewirkt wird.
  • Das Flussdiagramm von 4 beschreibt den Betrieb der lokalen RDR-Anwendung 308. Nach dem Betreten des Programms bei Schritt 402 werden die privaten API's 312, 314 und 316 installiert und geeignete Betriebssystem- und BIOS-„Haken" („hooks") werden installiert. Dies bewirkt, dass jedes anschließend geladene Programm unter Fernsteuerung betrieben wird. Bei Schritt 404 wird ein Menü an den Bediener des lokalen RDR-Computers 20 angeboten, was es ihm erlaubt, den Betrieb als ein neuer Benutzer oder ein vorregistrierter Benutzer zu bestimmen, oder die lokale RDR-Anwendung 308 zu beenden.
  • Wenn die Option neuer Benutzer gewählt wird, werden im Schritt 410 Routinen gestartet, welche die Hardware-Konfiguration des lokalen RDR-Computers bewerten. Der Benutzer wird dann bei Schritt 412 gebeten, die Formulare 2210 und 2220 mit Informationen bezüglich der Identität des Benutzers, Telefonnummern, etc. sowie einer Beschreibung der Umstände und Natur der Datenwiederherstellungssituation auszufüllen. Nach Fertigstellung der Formulare wird bei Schritt 414 ein Versuch unternommen, zu wählen und eine Kommunikation mit der Ferndatenwiederherstellungseinrichtung als neuer Benutzer herzustellen.
  • Wenn die Option vorregistrierter Benutzer gewählt wird, wird im Schritt 420 ein sofortiger Versuch unternommen, zu wählen und eine Kommunikation mit der Ferndatenwiederherstellungseinrichtung als vorregistrierter Benutzer herzustellen.
  • Wenn der Versuch der Verbindung mit der Ferndatenwiederherstellungseinrichtung als erfolglos bei Schritt 430 ermittelt wird, wird ein Dialog bei Schritt 440 an den Bediener des lokalen Computers angezeigt, der die fehlgeschlagene Verbindung anzeigt, und die Steuerung wird zum Menü zurückgesandt.
  • Wenn bei Schritt 430 festgestellt wird, dass die Verbindung mit der Ferndatenwiederherstellungseinrichtung erfolgreich ist, wird die ferngesteuerte Aktivität unter der vollständigen Führung der entfernten Stelle gemäß der Logik, die hierin später beschrieben ist, in Schritt 450 gehandhabt. Nach Fertigstellung wird die Kommunikationssitzung bei Schritt 460 unterbrochen und die Kommunikationshardware wird angewiesen, die Kommunikationssitzung zu unterbrechen.
  • Wenn die Option Beenden gewählt wird, entfernt die lokale RDR-Anwendung 308 die privaten API's 312, 314 und 316, sowie das zuvor installierte Betriebssystem und die BIOS-„Haken" bei Schritt 406.
  • 5 ist ein Flussdiagramm eines Teils der lokalen RDR-Anwendung 308, welcher während des Fernsteuerbetriebs ausgeführt wird. Der Initialisierung kritischer Datenstrukturen in Schritt 504 folgend, welche den Kommunikationspaketempfang und die Datenumleitungssteuerung regeln, betritt die lokale RDR-Anwendung 308 eine Schleife, Schritte 510 bis 550. Diese Schleife handhabt kontinuierlich in Schritt 510 alle Kommunikationsereignisse und fertigt alle Kommandos ab, welche von der Ferndatenwiederherstellungseinrichtung möglicherweise gesendet wurden. Sobald in Schritt 520 ermittelt wurde, dass ein vollständiges Fernkommando von der Ferndatenwiederherstellungseinrichtung empfangen und im lokalen Tastaturpuffer gespeichert wurde, wird das Fernkommando in Schritt 540 überprüft, um zu sehen, ob es ein Kommando zum Auflegen ist. Wenn ein Auflegekommando empfangen wurde, dann wird die Routine bei Schritt 560 verlassen. Wenn das Kommando kein Auflegekommando ist, wie bei Schritt 540 ermittelt, dann wird das Kommando bei Schritt 550 an den nativen Kommandozeilen-Interpreter des Betriebssystem weitergereicht. Man beachte, dass der lokale Tastaturpuffer von einem Kommando gefüllt wird, das von dem Ferneingabegerät 42, vorzugsweise einer Tastatur, herstammt. Falls bei Schritt 520 ermittelt wurde, dass kein vollständiges Kommando im lokalen Tastaturspeicher existiert, dann ermittelt eine Inaktivitätsauszeit bei Schritt 530 einen Kommunikationsfehler, und veranlasst eine geeignete Beendigung bei Schritt 560. Die korrespondierende Aktivität, die von der entfernten Stelle geregelt wird, ist in Referenz auf 12 beschrieben.
  • Das in 6 gezeigte Flussdiagramm beschreibt das Kommunikationsereignis-Steuerungsprogramm innerhalb der lokalen RDR-Anwendung 308. Das Kommunikationsereignis-Steuerungsprogramm wird von einer Vielzahl von Punkten innerhalb der lokalen Haken, beispielsweise Schritt 450, und vielen Betriebssystem- und BIOS-Haken aufgerufen. Die Absicht des Kommunikationsereignis-Steuerungsprogramms ist es, den Kommunikationstreiber zu betreuen, und irgendwelche ankommenden Pakete abzufertigen, Schritte 602 bis 630. Nach Initiierung des Kommunikationsereignis-Steuerungsprogramms bei Schritt 600 ermittelt die Routine bei Schritt 602, ob irgendwelche neuen Zeichen empfangen wurden. Wenn Zeichen empfangen wurden, dann werden die Zeichen im Empfangspuffer bei Schritt 605 pla ziert und dann wird eine Überprüfung bei Schritt 610 durchgeführt, um zu sehen, ob irgendwelche vollständigen Datenpakete im Empfangspuffer sind. Wenn irgendwelche vollständigen Pakete im Empfangspuffer existieren, dann werden diese vollständig geformten Pakete mit einer Liste von Paketempfangs-Kontrollstrukturen 2610 verglichen. Die Liste wird als eine einfach verlinkte Liste über das Zeigerverknüpfungsfeld 2612 gepflegt. Die Liste wird durchsucht, um eine passende Paketempfangs-Kontrollstruktur zu finden. Wenn das Typfeld des Pakets mit dem Pakettyp-Nummernfeld 2614 der Paketempfangs-Kontrollstruktur 2610 übereinstimmt, dann wird das Paketzählerfeld 2616 erhöht, und die Routine, auf die durch das Paketsteuerungsprogramm-Routinenzeigerfeld 2618 verwiesen wird, wird aufgerufen. Eine Anzahl von Paketsteuerungsprogramm-Routinen ist in 7 dargestellt, einschließlich dem Dateierzeugungs-/Öffnungs- oder Schließ-ACK-Paket, Schritt 700, dem Dateischreibe-Abfraglistenpaket, Schritt 710, Echo-Bestätigung, Schritt 720, Bildschirmveränderungs-Bestätigung, Schritt 730, Display-Datenpaket, Schritt 740, Tastenanschlagspaket, Schritt 750, Dateilesepaket, Schritt 760, und Echo-Anfragen, Schritt 770. Wenn jedoch das empfangene Paket wie bei Schritt 620 ermittelt, nicht übereinstimmt, dann wird das Paket bei Schritt 630 ignoriert und die Routine kehrt zurück bei Schritt 610 im Empfangspuffer nach kompletten Paketen zu suchen. Wenn keine neuen Zeichen bei Schritt 602 empfangen werden, dann wird bei Schritt 650 ein Anruf unternommen, um sicherzustellen, dass allen beliebigen Bildschirm-Aktualisierungen, welche aufgetreten sein können, welche jedoch nicht zuvor gesendet werden konnten, die Möglichkeit zu geben, die Übermittlungswarteschlange zu erreichen. Zusätzlich wird im Schritt 655 eine Ermittlung unternommen, um festzustellen, ob sich irgendwelche ausgehenden Pakete in der Übermittlungswarteschlange befinden. Wenn dies der Fall ist und wenn in dem Übermittlungspuffer wie bei Schritt 660 ermittelt, Platz verfügbar ist, dann wird das ausgehende Paket bei Schritt 670 an den Übertragungspuffer des Kommunikationstreibers angeheftet. Die Transmissionswarteschlange wird durch eine einfach verlinkte Liste ausgehender Paket-Deskriptoren wie bei 2510 von 25 gezeigt, implementiert. Jeder Paket-Deskriptor beinhaltet eine Verknüpfung 2511 zum nächsten Element der Liste, gefolgt von einer Zusammenstellung von Fragmentlänge- 2512 und Fragmentzeiger- 2514 Paaren. Jedes Paar beschreibt einen Speicherbereich, welcher das zu bildende und zu übertragende Paket umfassen würde. Die Zusammenstellung der Paare wird durch einen Eintrag mit einem Längenfeld von 0 wie bei 2516 gezeigt, unterbrochen. Die Pakete selbst werden mittels dieses „Gather-Write"-Prinzips, und, egal welche anderen Kodierungs-, Rahmungs- und Feh lersteuerungsverfahren einarbeitend, die durch den Implementierer vor dem Plazieren der Daten in dem Übertragungspuffer bei Schritt 670 für geeignet erachtet werden, gebildet.
  • 7 beinhaltet Flussdiagramme, die das Verhalten der lokalen RDR-Anwendung 308 repräsentieren, wenn sie verschiedene Pakettypen handhabt.
  • Dateierstellungsbestätigungs-, Dateiöffnungsbestätigungs- und Dateischließbestätigungs-Pakete werden bei Schritt 700 empfangen in Antwort auf jene Pakete, welche gesendet wurden, um anzufragen, dass die Datei-Erzeugungs-/Öffnungs-/Schließ-Handlung in der Ferndatenwiederherstellungseinrichtung auftritt. Diese Datei-Erzeugungs-/Öffnungs-/Schließ-Bestätigungspakete werden bei Schritt 702 gehandhabt lediglich durch Aktualisieren der geeigneten Dateisteuerungsstruktur 2520, um die Tatsache wiederzuspiegeln, dass die Anfrage bestätigt wurde, und um den Status der Datei-Erzeugungs-/Öffnungs-/Schließ-Handlung mitzuteilen. Dies erlaubt es der Datei-Erzeugungs-/Öffnungs-/Schließ-Handlung, welche bestätigt wird, fortzufahren. Bei Schritt 710 werden Dateischreibanfragen-Listenpakete empfangen in Antwort auf eine anfängliche Dateischreibanfrage. Diese Dateischreibanfrage-Listenpakete beinhalten eine Liste solcher Dateisegmente, für deren Empfang der Ferndatenwiederherstellungskommunikationsserver vorbereitet ist. Dateischreibanfragen-Listenpakte werden bei Schritt 712 durch Aktualisieren der Datei-Kontrollstruktur 2520 gehandhabt, um die neue Anfragenliste zurückzugeben und anschließend Dateischreib-Datenpakete bei Schritt 714 durch die aktualisierte Datei-Kontrollstruktur 2520 zu senden.
  • Zusätzlich setzt das Aktualisieren der Datei-Kontrollstruktur 2520 die Auszeit bei Schritt 716 zurück. Die Dateilese- und Schreibhaken werden ferner mit Referenz auf 10 beschrieben.
  • Echo-Bestätigungspakete werden bei Schritt 720 als Antwort auf eine Echoanfrage empfangen. Dieser Echo-Mechanismus wird für Kommunikationsdiagnose-Fähigkeiten bereitgestellt. Echo-Bestätigungspakete werden gehandhabt durch Kopieren des Dateninhalts in einem zugewiesenen Echopuffer in Schritt 722, derart, dass das Programm anschließend die Echodaten weiter analysieren kann.
  • Bildschirmänderungs-Bestätigungspakete werden bei Schritt 730 in Antwort auf Bildschirmänderungspakete empfangen. Bildschirmänderungs-Bestätigungspakete werden gehandhabt durch Markieren der Bildschirmänderung als nicht länger im Übergangszugang befindlich, bei Schritt 732.
  • Display-Datenpakete werden bei Schritt 740 empfangen als Anweisungen, Text auf dem lokalen RDR-Computermonitor 24 zu plazieren. Die Display-Datenpakete werden gehandhabt durch Kopieren der Paketdaten zum lokalen Display 24, bei Schritt 742, und dann Senden eines Display-Daten-Bestätigungspakets bei Schritt 744, um den Ferndatenwiederherstellungskommunikationsserver zu informieren, dass das Paket erfolgreich empfangen und auf dem lokalen Display 24 wiedergegeben wurde.
  • Tastenanschlagpakete werden bei Schritt 750 empfangen, wenn Tastenanschläge an der RDR-Workstation 40 auftreten, und sie werden durch den RDR-Kommunikationsserver 68 weitergeleitet. Die Tastenanschlagspakete werden gehandhabt durch Kopieren der Paket-Tastenanschlagsinformation bei Schritt 752 in den lokalen Tastaturpuffer. Dies erlaubt es der lokalen RDR-Anwendung 308, diese Tastenanschläge asynchron zu empfangen, und diese wie gewünscht zu interpretieren. Ein Tastenanschlags-Bestätigungspaket wird dann bei Schritt 754 zurückgegeben, nachdem die Tastenanschläge in dem lokalen Tastaturpuffer für eine anschließende Interpretation durch das Betriebssystem oder Anwendungsprogramme im lokalen RDR-Computer 20 gespeichert wurden.
  • Dateilesedatenpakete werden bei Schritt 760 in Antwort auf ein Dateileseanfrage-Listenpaket empfangen. Die Dateilese-Datenpakete beinhalten tatsächliche Ferndatei-Datensegmente, welche gelesen und durch den RDR-Kommunikationsserver 68 weitergeleitet wurden. Die Dateilesedatenpakete werden bei Schritt 762 gehandhabt durch Überprüfen, ob das Dateisegment die erwartete Segmentnummer in der Sequenz ist. Wenn nicht, wird bei Schritt 766 ein überarbeitetes Leseanfrage-Listenpaket gesendet. Wenn das eingehende Paket die erwartete sequenzielle Sequenznummer wie bei Schritt 762 ermittelt, enthalten hat, dann werden die Dateidaten zum Datenpuffer bei Schritt 764 kopiert. Echoanfragepakete werden bei Schritt 770 als eine Kommunikationsdiagnose-Anfrage empfangen. Auf solch ein Echoanfragepaket wird geantwortet durch Kopieren von Paketdaten bei Schritt 772 von dem Echoanfragepaket und Senden eines Echoantwortpakets bei Schritt 774.
  • 8 ist ein Flussdiagramm der Kommunikationspaketsenderoutine innerhalb der lokalen RDR Anwendung 308. Die Routine startet durch Platzieren des Pakets für die Übermittlung in die Übertragungswarteschleife bei Schritt 810. Wenn die lokale RDR Anwendung 308, die diese Routine 800 aufruft, angefragt hat, dass diese Routine 800 nicht auf eine Bestätigung (Acknowledgement, ACK) wie bei Schritt 830 ermittelt, wartet, dann führt die Routine bei Schritt 835 einen Anruf bei dem Kommunikationsereignissteuerungsprogramm bei Schritt 600 durch, um sicherzustellen, dass das Paket die Möglichkeit hat, übermittelt zu werden und endet dann mit einem Erfolgsstatus bei Schritt 890. Wenn die lokale RDR Anwendung 308 angefragt hat, dass diese Routine auf eine Bestätigung (ACK) warten soll, wie bei Schritt 830 ermittelt, wird eine Schleife betreten, welche die Kommunikationsereignisse handhabt, entweder bis ein ACK bei Schritt 850 auftritt, was zu einer erfolgreichen Beendigung bei Schritt 890 führt, oder bis eine Auszeitbedingung bei Schritt 860 ermittelt wird. Im Falle einer Auszeitbedingung wird die Sequenz der Übermittlung des Pakets und des Wartens auf eine Bestätigung eine beschränkte Anzahl von Malen erneut versucht, wie bei Schritt 870 festgelegt. Ein Fehler nachdem die Wiederholungszahl aufgebraucht ist, resultiert in einem Fehlerstatusabbruch bei Schritt 880.
  • 9 ist ein Flussdiagramm des Dateierzeugungs-/Öffnungs-/Schließ-Abfängers oder -„Hakens" innerhalb der lokalen RDR Anwendung 308. Diese Prozedur ist installiert, um einen Versuch durch die Anwendung vorzubelegen, jede beliebige Datei zu erzeugen, zu öffnen oder zu schließen. Das Verhalten dieses Hakens ist, zuerst zu ermitteln, ob die Datei eine entfernte oder lokale Datei ist, bei Schritt 910. Dies wird durchgeführt während Dateiöffnungungs-/Erzeugungshandlungen durch Überprüfen des Dateinamens, der durch den Aufrufer dieser Routine bereitgestellt wird, sei es die lokale RDR Anwendung 308 oder eine Datenwiederherstellungsanwendung 300, unter Verwendung jeder beliebigen Konvention für das Benennen von Ferndateien, welche diese einfach von lokalen Dateien unterscheiden kann, und wird während der Dateischließhandlungen ausgeführt durch Prüfen des Dateihandles, das von der lokalen RDR-Anwendung 308 bereitgestellt wird. Wenn ermittelt wird, dass die Datei lokal ist, durch den Test bei Schritt 910, wird die Ausführung zu der nativen Dateierzeugungs-/Öffnungs-/Schließ-Prozedur des Systems bei Schritt 912 übertragen. Wenn bei Schritt 910 ermittelt wird, dass die Datei entfernt ist, wird ein geeignetes Dateierzeugungsanfrage-, Dateiöffnungsanfrage-, oder Dateischließanfrage-Paket bei Schritt 920 konstruiert. Dieses Paket wird dann gesendet und es wird bei Schritt 930 auf eine Bestätigung gewartet. Die zurückempfangene Bestätigung reflektiert den Status der Anfrage beim entfernten Ende, welches den Inhalt der Dateikontrollstruktur 2520 bei Schritt 940 beeinflusst. Der Status wird dann an den Bediener des lokalen RDR-Computers 20 zurückgegeben gemäß der Dateierzeugungs-/Öffnungs-/Schließkonventionen des Systems. In dem Fall von Ferndateierzeugungsund/oder Öffnungsaktivitäten wird ein Dateihandle an den Aufrufer zurückgegeben, welches leicht von jedem beliebigen Dateihandle unterscheidbar ist, welches legitim von dem nativen Dateierzeugungs- oder Öffnungsprozess des Systems zurückgegeben worden sein kann. Dies erlaubt es zukünftigen Lese-/Schreib-/Schließ-Handlungen, lokale Dateien von entfernten Dateien zu unterscheiden.
  • 10 ist ein Flussdiagramm eines Dateilese- und Schreib-Abfängers oder -„Hakens" innerhalb der lokalen RDR-Anwendung 308. Diese Prozedur ist installiert, um jeden Versuch einer Anwendung vorzubelegen, jede beliebige Datei zu lesen oder zu schreiben. Das Verhalten dieses Hakens ist es, zuerst zu ermitteln, ob die Datei eine entfernte oder lokale Datei ist, bei Schritt 1010. Dies wird durchgeführt durch Prüfen des Filehandles, welches von dem Aufrufer dieser Routine bereitgestellt wird, sei es die lokale RDR-Anwendung 308 oder eine Datenwiederherstellungsanwendung 300. Wenn durch den Test ermittelt wird, dass die Datei lokal ist, bei Schritt 1010, wird die Ausführung zu der nativen Dateilese- oder Schreibprozedur des System bei Schritt 1012 übertragen. Wenn ermittelt wird, dass die Datei entfernt ist, dann wird die Dateikontrollstruktur 2520 aktualisiert, um die Natur der Anfrage bei Schritt 1020 wiederzugeben. Basierend auf dem Inhalt der Dateikontrollstruktur 2520 wird ein geeignetes Dateileseanfrage- oder Schreibanfrage-Paket erzeugt und bei Schritt 1030 gesendet. Es wird dann eine Schleife betreten bei Schritt 1040, welche fortfährt, die Kommunikationsereignisse, Schritt 600, zu handhaben und zu testen, ob die Lese- oder Schreibanfrage vollständig erfüllt wurde bei Schritt 1050. Wenn die Anfrage zufriedengestellt wurde, dann wird ein erfolgreicher Status an deren Aufrufer bei Schritt 1090 gemäß der nativen Dateilese-/Schreibkonventionen des Systems zurückgegeben. Wenn die Anfrage nicht komplett ist, wie bei Schritt 1050 ermittelt, werden Auszeitbedingungen bei Schritt 1060 kontrolliert. Wenn keine Auszeit aufgetreten ist, dann fährt die Routine fort, Kommunikationen bei Schritt 1040 zu handhaben und nach vollendeten Anfragen bei Schritt 1050 zu kontrollieren. Wenn eine Auszeit bei Schritt 1060 auftritt, dann wird die Anfrage bei Schritt 1030 eine beschränkte Anzahl von Wiederholungen erneut gesendet. Wenn die Anzahl an Wiederholungen aufge braucht ist, bei Schritt 1020, dann gibt die Anfrage einen Fehlerstatus, Schritt 1080, gemäß der nativen Dateilese-/Schreibkonventionen des Systems wieder.
  • Das Flussdiagramm der „Haken" der Bildschirmschreibe- und Lesefunktionen der lokalen RDR-Anwendung 308 ist in 11 gezeigt. Der Mechanismus schlägt Versuche vor, Bildschirmänderungen aufzuzeichnen und an die entfernte Stelle in einer zeitgemäßen Art und Weise mit minimalem Einfluss auf die Ausführung des Programms zu übermitteln. Die Bildschirmschreibfunktion wird implementiert, indem zuerst die gewünschte Bildschirmschreibinformation in einen internen Puffer bei Schritt 1110 kopiert wird, welcher den Status des Bildschirms vollständig beschreibt. Der Zweck diese Puffers ist es, den Bildschirmlesehaken bei Schritt 1170 zu ermöglichen, sowie die Quelle für Bildschirmaktualisierungspakete bereit zu stellen, wenn diese gebildet und übermittelt werden. Die bevorzugte Ausführungsform benutzt eine Bildschirmzeilenänderungsdeskriptor-Datenstruktur für jede Zeile von Zeichen in dem lokalen RDR-Computerdisplay 24. Diese Bildschirmzeilenänderungsdeskriptoren, die in 25 bei 2560 gezeigt sind, beschreiben für jede verbundene Zeile von Zeichen den Bereich der Spalten, für welchen die Zeichen durch Anwendungsprogramme modifiziert wurden, und jene modifizierten Zeichen wurden noch nicht in der Warteschleife für die Übertragung platziert. Dieser Bereich von modifizierten jedoch nicht gesendeten Spalten wird als der „schmutzige" Bereich für diese Zeile bezeichnet und wird durch den Bildschirmzeilenänderungsdeskriptor 2560 durch Einträge beschrieben, welche die erste (ganz linke) schmutzige Spalte 2562 und die letzte (ganz rechte) schmutzige Spalte 2564 für jede Bildschirmzeile markieren. Auf das Kopieren der neuen Bildschirmzeichen in den internen Puffer bei Schritt 1110 folgend werden die Bildschirmzeilenänderungsdeskriptoren für jede betroffene Bildschirmzeile modifiziert, um sicherzustellen, dass der „schmutzige" Bereich diese neu geschriebenen Spalten beinhaltet. Dann wird ein Anruf bei 1130 getätigt, um alle nicht gesendeten Bildschirmänderungen in der Übertragungswarteschleife 2510 für die anschließende Übertragung zu der RDR-Workstation 40 zu platzieren.
  • Versuche, Bildschirmänderungsbeschreibungen an die entfernte Stelle zu senden, werden in 1170 bis 1178 beschrieben. Wenn Bildschirmänderungsbeschreibungen gegenwärtig gesendet werden und unbestätigt sind, beispielsweise weil sie sich in Übermittlung befinden, wie bei Schritt 1172 ermittelt, dann wird kein Versuch unternommen, Bildschirmänderungsinformationen zu dieser Zeit zu senden. Wenn keine gegenwärtigen Bildschirmänderungsbeschreibun gen existieren, die nicht gesendete Bildschirmänderungen repräsentieren, ermittelt bei Schritt 1174, dann wird keine Handlung unternommen. Wenn die vorherigen Bedingungen nicht erfüllt werden, dann wird der letzte Bildschirmzeilenänderungsdeskriptor, der einen schmutzigen Bereich beschreibt, der nicht 0 ist, verwendet, um einen Eintrag bei 1178 in die Übertragungswarteschleife hinzuzufügen, welcher den entsprechenden Inhalt des schmutzigen Bildschirms vom internen Bildschirmpuffer senden wird. Die Bildschirmänderung befindet sich nun „in Übertragung" und der zugewiesene Bildschirmzeilenänderungsdeskriptor kann freigegeben werden. Wenn eine darauffolgende Bestätigung dieses Bildschirmzeilenänderungspakets empfangen wird, wird die Bildschirmänderung nicht länger als „in Übertragung" befindlich betrachtet, gemäß Schritt 730. Sollte eine Auszeit ohne Bestätigung auftreten, wird die Bildschirmzeilenänderungsbeschreibung erneut übermittelt.
  • Der Bildschirmlesefunktionshaken wird implementiert durch Kopieren der gewünschten Informationen in den Puffer des lokalen RDR-Computers direkt vom internen Bildschirmdarbietungspuffer bei Schritt 1180.
  • Die Hauptanwendung, welche die RDR-Kommunikationsserveranwendung in eine Ausführungsform der vorliegenden Erfindung implementiert, ist im Flussdiagramm von 12 beschrieben. Typischerweise wird ein Anwendungs-Thread für eine Netzwerkkommunikationshardwareeinheit 69 gestartet, welche die Schritte 1210 bis 1280 ausführt. Nach dem Empfangen eines eingehenden Telefonanrufs wird eine ASCII-Anzeige übertragen, die den Bediener des lokalen RDR-Computers 20 auffordert, den gewünschten Servicetyp einzugeben. Dies erlaubt die Verwendung des Ferndatenwiederherstellungskommunikationsservers bei herkömmlichen „dummen" Terminalanwendungen sowie bei hoch automatisierten Rufübertragungen von der lokalen RDR-Anwendung 308.
  • In einer typischen Situation, in der die RDR-Kommunikationsserveranwendung durch einen beliebigen Benutzer mit einem dummen Terminal aufgerufen wird, kann der Benutzer auf die Anzeige antworten, gesetzt bei Schritt 1210, als ein „Gast". Dies veranlasst die RDR-Kommunikationsserveranwendung, sich wie ein klassischer Service eines schwarzen Bretts zu verhalten, mit einer Funktionalität, die nur durch die Kreativität des Programmierers und die Möglichkeiten der lokalen Terminalanwendung des Bedieners beschränkt ist. Die Zweckmäßigkeit dieser „Gast"-Kategorie des Service ist, dass sie verwendet werden kann, um für die Services/Produkte der Organisation zu werben, in der Art und Weise einer klassischen BBS. Ferner kann sie als eine Downloadeinrichtung verwendet werden, um die Verteilung der lokalen RDR-Anwendung 308 und damit verbundener Programme zu erlauben.
  • Sobald die lokalen RDR-Anwendungsprogramme im Besitz des lokalen Benutzers sind, kann der lokale Benutzer die Anwendungen installieren und anwenden, um die Kategorie „neuer Benutzer" des Service von der RDR-Kommunikationsserveranwendung aufzurufen. Die lokale RDR-Anwendung 308 ist von dem Anzeigesatz bei Schritt 1210 und den Antworten, welche von der RDR-Kommunikatonsserveranwendung erwartet werden und welche in 4 beschrieben sind, unterrichtet.
  • Bei Schritt 1225 ermittelt die RDR-Kommunikationsserveranwendung, ob die lokale RDR-Anwendung 308 die „neuer Benutzer"-Kategorie des Service bei Schritt 404 abfragt. Die Dateien, welche an der lokalen Stelle erzeugt wurden, die die Hardwarekonfiguration, die Benutzerinformation und die Problembeschreibung in den Schritten 410 und 412 beschreiben, werden zu der Ferndatenwiederherstellungseinrichtung für eine weitere Analyse und das Hinzufügen zu einer Datenbank registrierter Benutzer in Schritt 1230 kopiert. Wenn festgestellt wird, dass es nicht möglich ist, mit der Ferndatenwiederherstellung zur gegenwärtigen Zeit bei Schritt 1234 fortzufahren, wird ein Menü angeboten und es wird eine Zeit ausgehandelt, bei Schritt 1238, bei der mit dem Ferndatenwiederherstellungsverfahren fortgefahren wird.
  • Zu dem Termin, zu welchem zuvor ausgehandelt wurde, die RDR-Prozedur zu starten, fragt die lokale RDR-Anwendung 308 die „zuvor registrierter Benutzer"-Kategorie des Service von der RDR-Kommunikationsserveranwendung bei Schritt 1235 ab. Solche Anrufe werden dann gegen die Datenbank der registrierten Benutzer bei Schritt 1240 authentifiziert. Nicht authentifizierte Anrufe werden unterbrochen. Da individuelle Kommunikationsverbindungen aufgebaut werden und der Fortschritt durch die verschiedenen Stufen in 12 verdeutlicht wird, kann der Status des Fortschritts auf der Konsole des Kommunikationsservers 68 des Bedieners in einem Kommunikationskanalstatusfenster 2310, beispielsweise wie es in 23 gezeigt ist, beschrieben werden.
  • Wenn es dem „neuer Benutzer"-Service erlaubt war, mit der RDR-Prozedur unmittelbar in Schritt 1234 fortzufahren, oder alternativ nach einer erfolgreichen Authentifizierung eines vorregistrierten Benutzers in Schritt 1240, wird ein RDR-Diagnoseverfahren in Schritt 1250 durchgeführt. Das Diagnoseverfahren ist im Detail in Referenz auf 14 beschrieben. Ein Benutzerlizenzvertrag, der die Bedingungen jedes beliebigen vorgeschlagenen Datenwiederherstellungsservice beschreibt, wird erzeugt und dann dem Bediener des lokalen RDR-Computers 20 in Schritt 1260 angeboten. Die Übertragung und Verarbeitung des Lizenzvertrages ist im Detail in 15 beschrieben. Sollte der Bediener des lokalen RDR-Computers 20 den Bedingungen des Vertrags zustimmen, wie ermittelt in Schritt 1270, dann wird die Ferndatenwiederherstellungsprozedur durchgeführt in Schritt 1280. Die Ferndatenwiederherstellungsprozedur ist im Detail in Referenz auf 16 beschrieben.
  • Das Flussdiagramm von 13 beschreibt den Teil der RDR-Kommunikationsserveranwendung, welche, für welchen Grund auch immer, aufgerufen wird, wenn ermittelt wurde, dass das Datenwiederherstellungsverfahren stattfinden sollen nach dem anfänglichen Registrierungstelefonanruf bei Schritt 1234. Eine Datei, welche den Zeitplan pflegt und sich auf dem netzwerkfreigegebenen Datenspeicher 64 des Fileservers 60 befindet, wird bei Schritt 1310 gelesen. Die Datei wird dann bei Schritt 1320 mit den Bedürfnissen dieser speziellen vorliegenden Datenwiederherstellungssituation ausgeführt, um eine Liste von geeigneten Zeitplanzeiten für das Durchführen des RDR-Verfahrens zu ermitteln. Solche Faktoren wie die geschätzte Zeit für die Durchführung der Wiederherstellung, die spezifische Technikerverfügbarkeit und andere Priorisierungsfaktoren können verwendet werden, um diese angepasste Liste von geeigneten Zeiten für die Bereitstellung des Ferndatenwiederherstellungsservice zu erzeugen. Eine Anwendung wird auf dem lokalen Computer bei Schritt 1330 aktiviert, welche es dann ermöglicht, die angepasste Zeitplanliste anzusehen und optional eine gemeinsam zustimmungsfähige Zeit für das Fortfahren mit der Ferndatenwiederherstellung auszuwählen. Wenn solch eine Zeit im Schritt 1340 ausgewählt wird, wird diese bei Schritt 1350 der Zeitplandatei hinzugefügt. Wenn keine solche Zeit bei Schritt 1340 ausgewählt wurde, wird eine Beschreibung weiterer Optionen an den Bediener des lokalen RDR-Computers 20 bei Schritt 1360 angezeigt. Die Optionen, die in Schritt 1360 angezeigt werden, können das Einsenden der Ausrüstung in die Ferndatenwiederherstellungseinrichtung für eine herkömmliche Wiederherstellung an entfernter Stelle, oder das Anfragen von Datenwiederherstellungsservices der vor-Ort-Kategorie beinhalten.
  • 14 ist ein Flussdiagramm des Teils des Ferndatenwiederherstellungskommunikationsservers, welcher die Durchführung der Datenwiederherstellungsdiagnose ermöglicht. Zuerst wird in Schritt 1410 eine Überprüfung durchgeführt, um zu sehen, ob eine gültige Kopie der gegenwärtigen Version der Diagnoseanwendung auf dem Distributionsmedium an der lokalen Stelle vorhanden ist. Wenn eine gültige Kopie dieser Diagnoseanwendung nicht vorhanden ist, oder wenn keine geeignete Version der Diagnoseanwendung vorhanden ist, wird eine geeignete Version der Diagnoseanwendung an die lokale Stelle bei Schritt 1420 heruntergeladen. Anschießend, oder wenn ermittelt wurde, dass eine geeignete Diagnoseanwendung existiert, in Schritt 1410, wird die Diagnoseanwendung am lokalen Computer in Schritt 1430 aktiviert. Die Diagnoseanwendung führt eine Diagnose der Datenwiederherstellungssituation durch und platziert die Ergebnisse in einer Datei auf dem Kommunikationsserver 68 in Schritt 1440 für die weitere Analyse durch den Ferntechniker und/oder andere Anwendungen an der Ferndatenwiederherstellungseinrichtung.
  • 15 ist ein Flussdiagramm eines Teils der Ferndatenwiederherstellungskommunikationshardwareanwendung, welche die Präsentation und optional die Annahme des rechtlichen Übereinkommens durch den Bediener des lokalen RDR-Computers 20 ermöglicht. Zuerst wird in Schritt 1510 eine Überprüfung durchgeführt, um zu sehen, ob eine gültige Kopie der gegenwärtigen Version des rechtlichen Übereinkommens auf dem Distributionsmedium am Ort des Benutzers existiert. Wenn das rechtliche Übereinkommen nicht existiert oder es sich nicht um eine geeignete Version handelt, wird eine geeignete Version des rechtlichen Übereinkommens an die lokale Stelle bei Schritt 1520 heruntergeladen. Folgend dem Herunterladen 1520 oder einer Feststellung, dass das geeignete rechtliche Übereinkommen etabliert ist bei Schritt 1510, werden bei Schritt 1530 das aktuelle Datum und die Zeit notiert. Eine Übereinkommens-Leseanwendung wird dann am lokalen RDR-Computer 20 bei Schritt 1540 aktiviert. Die Übereinkommens-Leseanwendung erlaubt es dem Bediener des lokalen RDR-Computers 20, das rechtliche Übereinkommen einzusehen und optional die darin enthaltenen Bedingungen zu akzeptieren. Die Akzeptanz-/Ablehnungsantwort, die von dem Bediener durchgeführt wird, sowie das aktuelle Datum und die Zeit werden wiederum bei Schritt 1550 notiert. Ein genaues Wissen des Datums und der Zeit der Präsentation des Übereinkommens und der Akzeptanz des Übereinkommens zu besitzen, können relevante Faktoren beim Lösen von irgendwelchen möglichen Auseinandersetzungen sein, welche bezüglich bestrittener Übereinkommen aufkommen können.
  • 16 ist ein Flussdiagamm des Teils der Ferndatenwiederherstellungskommunikationsserveranwendung, welcher die Ferndatenwiederherstellung durchführt. Dieses Verfahren wird durchgeführt, indem es einem Techniker, der eine RDR-Workstation 40 bedient, ermöglicht wird, den lokalen RDR-Computer 20 fernzusteuern. Eine logische Verbindung wird bei Schritt 1610 über TCP/IP mit einer beliebigen RDR-Workstation 40 ausgebildet, welche verfügbar ist, ein Ferndatenwiederherstellungsverfahren durchzuführen. Zusätzlich wird ein eindeutiges Unterverzeichnis für diese Sitzung der Ferndatenwiederherstellung bei Schritt 1620 auf dem netzwerkfreigegebenen Datenspeicher 64 des Fileservers 60 erzeugt. Dieses einzigartige Unterverzeichnis ist das Depot für alle sitzungseindeutigen Dateien, die vom Bediener des lokalen RDR-Computers erzeugt werden, sowie für alle Log-Dateien, welche die RDR-Kommunikationsserveranwendung der RDR-Workstation 40 anlegen möchte. Eine Schleife, Schritte 1640 bis 1660, wird dann betreten, welche alle beliebigen Kommunikationspakete vom lokalen Computer 20 bei Schritt 1640, sowie alle beliebigen TCP/IP-Nachrichten von der RDR-Workstation 40 bei Schritt 1650 abarbeitet. Wenn ermittelt wird, dass keine „Auflege"-Nachricht von der RDR-Workstation 40 bei Schritt 1660 empfangen wurde, dann besteht die Schleife weiter. Schließlich veranlasst der Bediener der RDR-Workstation, dass eine „Auflege"-Nachricht gesendet wird, welche die Schleife bei Schritt 1660 durchbricht und veranlasst, dass ein „Auflege"-Kommando an den lokalen RDR-Computer 20 bei Schritt 1670 weitergeleitet wird.
  • 17 ist ein Flussdiagamm eines Teils der RDR-Kommunikationsserveranwendung, welche auf Pakete antwortet, die von dem lokalen RDR-Computer 20 über die Netzwerkkommunikationshardwareeinheit 69 ankommen, welche anfragen, dass eine entfernte Datei geöffnet, erzeugt oder geschlossen wird. Das Paket enthält einen Dateiindex, welcher von 0 bis zur maximalen Zahl gleichzeitig offener Dateien reicht sowie eine Sequenznummer, welche verwendet wird, um diese Anfrage als eindeutige Benutzung des Dateiindex zu unterscheiden. Es ist deshalb möglich, eine Kombination von Dateiindex und Sequenznummer zu verwenden, um zu ermitteln, ob dies eine einzige Anfrage ist oder ob dies ein erneuter Versuch einer Anfrage ist, für welche die Bestätigung aufgrund eines Fehlers im Kommunikationskanal 35 verloren wurde. Wenn ermittelt wird, dass dies keine Wiederholung einer vorherigen Anfrage ist, bei Schritt 1710, wird die Datei geöffnet/erzeugt/geschlossen gemäß des Restes des Pakets bei Schritt 1720. Wenn die Anfrage tatsächlich eine wiederholte Anfrage ist, wie bei Schritt 1710 ermittelt, dann wird das tatsächliche Öffnen/Erzeugen/Schließen der Datei umgangen. Wenn die Öffnen-/Erzeugen-/Schließen-Anfrage nicht erfolgreich ist, wie bei Schritt 1730 ermittelt, wird eine Fehlerbestätigung bei Schritt 1760 übermittelt. Alternativ, wenn die Feststellung bei Schritt 1730 derart ist, dass die Öffnen-/Erzeugen-/Schließen-Anfrage erfolgreich war, dann werden die Dateiverbindungsdatenstrukturen innerhalb des Ferndatenwiederherstellungskommunikationsservers bei Schritt 1740 initialisiert, gemäß des Öffnen-/Erzeugen-/Schließen-Anfragepakets, und dann wird bei Schritt 1750 eine Erfolgsbestätigung gesendet.
  • 18 ist ein Flussdiagramm des Teils der RDR-Kommunikationsserveranwendung, welcher auf jene Pakete antwortet, die von dem lokalen RDR-Computer 20 über die Netzwerkkommunikationshardwareeinheit 69 ankommen, welche die Dateischreibeaktivität anfordern. Das erste empfangene Paket ist ein Schreibe-Datei-Initialisierungspaket, welches gegen diese Sequenznummer dieser letzten Aktivität auf der Datei überprüft wird, um zu sehen, ob es ein erneuter Versuch einer zuvor empfangenen Anforderung ist, bei Schritt 1810. Wenn ermittelt wird, dass dies kein erneuter Versuch ist, bei Schritt 1810, wird die Initialisierung einschließlich der Speicherzuweisung für die Aktivität sowie die Erstellung der Initialdateisteuerungsstruktur 2620 bei Schritt 1850 durchgeführt. Wenn ermittelt wird, dass es kein erneuter Versuch ist, bei Schritt 1810, dann wurde die Initialisierung bereits durchgeführt, jedoch die Bestätigung wurde aufgrund eines Kommunikationsfehlers verloren und daher wird die Initialisierung übersprungen. In jedem Fall fährt der Ablauf weiter fort zu Punkt A von 18, was der Beginn des Algorithmus ist, welcher ermittelt, wie auf das Dateischreibepaket zu antworten ist. Eine Überprüfung wird durchgeführt bei Schritt 1860, um zu ermitteln, ob alle Schreibdaten empfangen wurden, um das gesamte Schreibdateiinitialisierungspaket zu erfüllen. Wenn alle Daten empfangen wurden, werden alle beliebigen Daten, welche sich in Speicherpuffern befinden, tatsächlich bei Schritt 1860 in die Datei geschrieben. Der Speicher, welcher bei Schritt 1850 zugewiesen wurde, wird nun bei Schritt 1870 freigegeben und eine Nullanfrageliste wird bei Schritt 1880 gesendet, um anzuzeigen, dass das Schreiben der Datei vollständig ist. Wenn während des Tests bei Schritt 1860 ermittelt wurde, dass keine weiteren Dateidaten zu empfangen waren, wird ein geeignetes Schreibeanfragelistenpaket entworfen und gesendet bei Schritt 1890. Diese Anfrageliste fordert jene Dateidatensegmente an, für welche die Daten noch nicht empfangen wurden und für welche verfügbarer Pufferplatz existiert, welcher gegenwärtig keine ungeschriebenen Daten enthält.
  • Während Dateischreibedatenpakete in Antwort auf Dateischreibedatenanfragepakete ankommen, wird eine Entscheidung getroffen, bei Schritt 1815, ob dies eine Wiederholung ist oder nicht, basierend auf der Sequenznummer in dem Paket. Wenn es eine Wiederholung ist, dann fährt das Verarbeiten bei Punkt A fort. Wenn ermittelt wird, dass es keine Wiederholung ist, dann werden die Paketdaten bei Schritt 1820 in den Puffer kopiert, welcher bei Schritt 1850 zugewiesen wurde. Wenn ermittelt wird, dass die Sequenznummer nicht in der geeigneten Sequenz ist, bei Schritt 1825, dann wird die Anfrageliste bei Schritt 1845 angepasst, um eine erneute Anfrage jedes Segments/aller Segmente zu veranlassen, welches) nicht empfangen wurde(n). Wenn ermittelt wird, dass das Segment in der Sequenz ist, bei Schritt 1825, wie es der Fall ist in Abwesenheit von Kommunikationsfehlern, wird ein Test bei Schritt 1830 durchgeführt, um zu sehen, ob die Dateischreibeaktivität gegenwärtig stattfindet. Wenn keine Dateischreibeaktivität vorliegt, dann wird ein Dateischreiben bei Schritt 1835 von allen beliebigen Datenpuffern initiiert, welche ungeschriebene Dateidaten enthalten. Die Anfrageliste wird dann bei Schritt 1840 angepasst, um bisher jene bisher empfangenen Dateisegmente zu berücksichtigen, sowie alle beliebigen Dateidatenpuffer, welche nun frei sind, um weitere Daten zu empfangen. Das Verarbeiten fährt dann bei Punkt A fort.
  • 19 beschreibt verschiedene Paketsteuerungsprogramme, welche in der Ausführungsform der RDR-Kommunikationsserveranwendung existieren. Echoanfragepakete werden gehandhabt in der Routine, die bei Schritt 1900 startet, durch Senden eines Echobestätigungspakets bei Schritt 1902, welches eine Kopie aller beliebigen optionalen Echodaten enthält, welche sich in dem Originalechoanfragepaket befanden. Dateileseanfragelistenpakete enthalten eine Liste von Segmenten der Datei, für welche der lokale Benutzer bereit ist, Daten zu empfangen. Diese Dateileseanfragelistenpakete werden von der Routine, die bei Schritt 1910 startet, gehandhabt, durch Durchführen des tatsächlichen Lesens bei Schritt 1920 und dann Senden der Daten bei Schritt 1930 in der Form von Dateilesedatenpaketen. Bildschirmänderungspakete, gehandhabt von der Routine, die bei Schritt 1939 startet, werden bei Schritt 1940 getestet, um zu sehen, ob diese Wiederholungen eines Pakets, das bereits verarbeitet wurde, sind. Dieser Test wird wie mit vielen anderen Paketen kraft der Sequenznummer, die innerhalb des Pakets enthalten ist, durchgeführt. Wenn ermittelt wird, dass das Paket keine Wiederholung ist, bei Schritt 1940, wird es dann bei Schritt 1950 verarbeitet durch Weiterleiten an die Ferndatenwiederherstellungsworkstation über eine TCP/IP Verbindung. Auf diese Tätigkeit folgend oder, wenn ermittelt wurde, dass das Paket eine Wiederholung ist, wird ein Bildschirmänderungsbestätigungspaket bei Schritt 1960 an den lokalen RDR-Computer 20 gesendet.
  • 20 ist ein Flussdiagramm, das einen Thread der Ausführung, Schritt 2002 bis 2008, repräsentiert, welcher kontinuierlich innerhalb der Kommunikationsserveranwendung für das Überwachen der Ferndatenwiederherstellungsworkstation-Verbindungen arbeitet, sowie einen Thread der Ausführung repräsentiert, welcher kontinuierlich Nachrichten von RDR-Workstations 40 handhabt, während diese aktiv in Ferndatenwiederherstellungshandlungen einbezogen sind.
  • Der Verbindungsüberwachungs-Thread, die Schritte 2002 bis 2008, überwacht einen TCP/IP Port, welcher allen RDR-Workstations 40 auf dem System bekannt ist. Die RDR-Kommunikationsserveranwendung wartet bei Schritt 2002 auf jede beliebige RDR-Workstation 40, eine TCP/IP-Verbindung aufzubauen. Deshalb baut jede beliebige RDR-Workstation 40, welche deren RDR-Workstationanwendung, später diskutiert in Referenz auf 21, aktiviert, eine logische Verbindung über diesen Port auf. Nachdem eine TCP/IP-Verbindung auf diesem Port aufgebaut ist, wird ein weiterer Thread der Ausführung erzeugt, bei Schritt 2006, welcher Nachrichten von der RDR-Workstation 40 handhabt. Die RDR-Workstation 40, die so verbunden ist, wird bei Schritt 2008 notiert, dass sie in der Lage ist, einen Ferndatenwiederherstellungsservice auszuführen. Solche RDR-Workstationverbindungen, die so bei Schritt 2008 notiert werden, können auf der Konsole des Bedieners des Kommunikationsservers 68 in einem Workstationstatusfenster 2320 wie in 23 gezeigt beschrieben werden.
  • Der Thread, Schritte 2010 bis 2075, der bei Schritt 2006 erzeugt wird als ein Ergebnis der TCP/IP-Verbindung, ist für die Handhabung aller TCP/IP-Nachrichten verantwortlich, die von der RDR-Workstation 40 gesendet werden. Ein separater Thread dieser Sorte existiert innerhalb der RDR-Kommunikationsserveranwendung für alle RDR-Workstations 40, welche derzeit als potentielle Anbieter eines Ferndatenwiederherstellungsservice etabliert sind. Diese Threads beginnen das Empfangen von Nachrichten, wenn der Bediener der RDR-Workstation 40 eine Aktivität in der Durchführung der Ferndatenwiederherstellung durchführt.
  • Spezielle TCP/IP-Nachrichten werden im Allgemeinen gehandhabt durch Weiterleiten dieser Nachrichten an den lokalen RDR-Computer 20 über verschiedene Pakete über die Kommunikationshardware. Diese TCP/IP-Nachrichten, welche Tastenanschläge repräsentieren, werden bei Schritt 2020 detektiert und bei Schritt 2025 an den lokalen RDR-Computer 20 als Tastenanschlagspakete weitergeleitet. Die TCP/IP-Nachrichten, welche Displaynachrichten repräsentieren, werden bei Schritt 2030 detektiert und bei Schritt 2035 an den lokalen RDR-Computer 20 als Displaydatenpakete weitergeleitet. Ähnlich wird eine „Auflege"-TCP/IP-Nachricht bei Schritt 2040 ermittelt und bei Schritt 2045 weitergeleitet, um zu veranlassen, dass der lokale RDR-Computer 20 die Telefonverbindung auflegt. Der verbleibende TCP/IP-Nachrichtentyp ist die „Abmelde"-Nachricht, welche auftritt als Ergebnis, wenn der RDR-Workstationbediener die RDR-Workstationanwendung beendet. Wenn die „Abmelde"-Nachricht bei Schritt 2050 ermittelt wird, veranlasst dies die RDR-Kommunikationsserveranwendung bei Schritt 2075 zu notieren, dass diese RDR-Workstation 40 nicht länger bereit ist, Ferndatenwiederherstellungsservices zu verarbeiten. Die TCP/IP-Verbindung wird dann geschlossen und dieser Thread der Ausführung wird bei Schritt 2080 beendet.
  • 21 ist ein Flussdiagramm, das den Gesamtbetrieb der Anwendung repräsentiert, welche die RDR-Workstation 40 steuert. Nach Aufruf der RDR-Workstationanwendung bei Schritt 2100 wird eine logische Verbindung bei Schritt 2110 mit einer RDR-Kommunikationsserveranwendung über einen vordefinierten festen TCP/IP-Port auf dem RDR-Kommunikationserver 68 etabliert. Eine Schleife, Schritte 2115 bis 2120, wird dann betreten, welche wartet bis entweder der Workstationbediener anfragt, dass die Anwendung beendet wird, bei Schritt 2115, oder bis eine TCP/IP-Nachricht bei Schritt 2120 von der RDR-Kommunikationsserveranwendung ankommt, die den Start der Ferndatenwiederherstellungssitzung anfordert. Der Kommunikationsserver 68 erteilt eine TCP/IP-Anfrage, um die Ferndatenwiederherstellungssitzung bei Schritt 1610 zu starten. Diese Anfrage 1610 wird von der RDR-Workstation 40 bei Schritt 2120 detektiert und eine Sammlung von Fenstern 2410, 2420 und Steuerelementen 2430, 2440 werden auf der RDR-Workstationkonsole 44, wie in 24 dargestellt, gezeichnet.
  • Die Makrosteuerungsschaltflächen 2430 werden bereitgestellt, um eine „Makro"-Fähigkeit zu erlauben, derart, dass die Aktivierung jeder beliebigen individuellen Schaltfläche das Äqui valent vieler vordefinierter Tastenanschläge ausfertigt. Die Statussteuerungsschaltflächen 2440 werden bereitgestellt, um die Möglichkeit der Auflistung von Statusnachrichten für die Anzeige auf der RDR-Lokalkomputerkonsole 24 zu ermöglichen.
  • Bei Schritt 2130 werden alle beliebigen Bildschirmaktualisierungsnachrichten, welche von dem lokalen RDR-Computer 20 bei Schritt 1170 gesendet wurden, anschließend von dem Kommunikationsserver 68 bei Schritt 1950 weitergeleitet und über TCP/IP empfangen wurden, auf dem Fenster 2410 abgebildet. Folglich zeigt das Fenster 2410 alle Bildschirmaktivitäten, die von jenen Datenwiederherstellungsanwendungsprogrammen 300 durchgeführt werden, die auf dem lokalen RDR-Computer 20 arbeiten.
  • Bei Schritt 2135 werden alle Tastenanschläge von der RDR-Workstationtastatur 42 über TCP/IP an den Kommunikationsserver 68 für die Weiterleitung 2020, 2025 an den lokalen RDR-Computer 20 als Tastenanschlagspakete gesendet. Diese Tastensanschlagpakete werden vom lokalen RDR-Computer 20 wie bei den Schritten 750 und 755 in 7 gezeigt, empfangen, was es folglich dem Bediener der RDR-Workstation 40 erlaubt, die Datenwiederherstellungsanwendungsprogramme 300 zu steuern, die auf dem lokalen RDR-Computer 20 arbeiten. Bei Schritt 2140 werden alle beliebigen Displaydatennachrichten, welche über die Aktivierung der Steuerungsschaltflächen 2440 festgelegt wurden, über TCP/IP an den Kommunikationsserver 68 für das Weiterleiten 2030, 2035 an den lokalen RDR-Computer 20 als Displaydatenpakete gesendet. Der lokale RDR-Computer 20 handhabt diese Pakete durch Kopieren dieser an den lokalen Bildschirm bei Schritt 742. Zusätzlich werden bei Schritt 2140 diese Displaydatennachrichten auf dem Fenster 2420 derart angezeigt, dass das Fenster 2420 eine genaue Darstellung des Aussehens der lokalen RDR-Computerkonsole 24 aufrecht erhält. Wenn bei Schritt 2150 festgestellt wird, dass die Sitzung vollständig ist, wird eine „Auflege"-Nachricht an den Kommunikationsserver 68 gesendet und die Fenster 2410 und 2420 und Steuerungen 2430 und 2440 werden bei Schritt 2155 gelöscht.
  • 22 enthält Abbildungen von Computerbildschirmen, die Formulare repräsentieren, die auf dem lokalen Display 24 abgebildet werden, welche der Benutzer des lokalen RDR-Computers 20 ausfüllen kann, um Informationen bezüglich der Identität des Benutzers, der Natur der gegenwärtigen Datenverlustsituation und der entsprechenden gewünschten Services bereitzustellen. Die Benutzeridentifikation und andere relevanten Informationen werden von dem Formular 2210 ermittelt. Information, die für eine korrekte Diagnose des Datenverlusts relevant sind, und die für das Beschreiben des gewünschten Service relevant sind, werden dadurch ermittelt, dass der Benutzer das Formular 2220 ausfüllt.
  • 23 enthält Abbildungen von Computerbildschirmen, die von der Kommunikationsserveranwendung angezeigt werden, welche die Administratoren der Ferndatenwiederherstellungseinrichtung unterstützen, den Kommunikationsserver 68 zu verwalten. Ein Kommunikationskanalstatusfenster 2310 wird bereitgestellt, um das Überwachen des Status jedes konfigurierten LAN-Kommunikationskanals 66 zu erleichtern. Jeder LAN-Kommunikationskanal 66 kann sich in einem Wartemodus, einem Gastmodus, einem Neuerbenutzermodus oder einem aktiven Datenwiederherstellungsmodus befinden oder kann Offline sein. Zusätzliche Steuerungen können bereitgestellt werden, um die Wartung und Konfiguration von individuellen LAN-Kommunikationskanälen 66 oder des Kommunikationsservers 68 als Ganzes zu erleichtern. Zusätzlich wird ein Workstationstatusfenster 2320 bereitgestellt, um die Überwachung jener Ferndatenwiederherstellungsworkstations 40 zu ermöglichen, welche TCP/IP-Verbindungen zu dem Kommunikationsserver 68 aufgebaut haben, sowie eine Anzeige bezüglich der gegenwärtigen Aktivität, die an jenen Ferndatenwiederherstellungsworkstations 40 ausgeführt wird.
  • 24 enthält Abbildungen von Computerbildschirmen, welche auf dem RDR-Workstationdisplay 44 angezeigt werden können. Diese Bildschirme erlauben es dem Benutzer der RDR-Workstation 40 die Ausgabe von Programmen des lokalen RDR-Computers 20 zu steuern und zu kontrollieren, sowie die Erscheinung des tatsächlichen Bildschirms des lokalen RDR-Computerdisplays 24 zu steuern und zu kontrollieren. Das lokale Programmausgabefenster 2410 ist eine Anzeige der Ausgabe einer RDR-Anwendungen 300. Diese Ausgabe ermöglicht es dem Bediener der RDR-Workstation 40, die Anwendungen zu kontrollieren, die auf dem lokalen RDR-Computer 20 laufen. Die Makrosteuerungsschaltflächen 2430 stellen Verfahren für den Bediener der RDR-Workstation 40 bereit, häufig verwendete Tastenanschlagsequenzen an den lokalen RDR-Computer 20 zu senden. Die Verwendung der Statussteuerungsschaltflächen 2440 erlaubt es dem Benutzer der RDR-Workstation 40, vorkonfigurierte oder angepasste Statusnachrichten auf dem lokalen RDR-Computerdisplay 24 anzeigen zu lassen. Das tatsächliche lokale Displayfenster 2420 ist dann eine Anzeige, welche dem Inhalt des lokalen RDR-Computerdisplays 24 folgt. Dies erlaubt es dem Bediener der RDR-Workstation 40, von den Statusnachrichten unterrichtet zu bleiben, welche angezeigt wurden.
  • 25 enthält beschreibenden Zeichnungen der Datenstrukturen, die in einer Ausführungsform der lokalen RDR-Anwendung 300 verwendet werden. Das Diagramm 2510 beschreibt eine Datenstruktur des Ausgangspaketbeschreibers (Outgoing Packet Decriptor, OPD). Dieser OPD 2510 und alle beliebigen OPD's, welche über den Linklistenzeiger 2511 verbunden sind, umfassen die Übertragungswarteschleife innerhalb des Kommunikationssubsystemcodes 318 der lokalen RDR-Anwendung 308. Der Rest der Datenstruktur besteht aus Paaren von Fragmentlängenfeldern 2512 und Fragmentzeigerfeldern 2514. Jede beliebige Zahl solcher Paare von Fragmentlängenfeldern 2512 und Fragmentzeigerfeldern 2514 kann existieren, bis ein Paar mit einem Null-Fragmentlängenfeld 2516 angetroffen wird, welches die Liste der Paare beendet. Jedes Paar beschreibt eine Speicherregion, welche einen Teil des ausgehenden Pakets umfasst. Dies ist ein klassischer „gather-write"-Ansatz, welcher es erlaubt, dass die Sammlung von verschiedenen Teilen des ausgehenden Pakets von weit getrennten Speicherregionen gesammelt werden.
  • Das Diagramm 2520 verdeutlicht eine lokale Dateisteuerungsstruktur (local file control structure, Lokale FCS). Eine solche lokale FCS 2520 existiert für jede potentielle gleichzeitige Instanz einer offenen entfernten Datei innerhalb der lokalen Ferndatenwiederherstellungsanwendung 308. Weiteren Einblick in die Verwendung dieser Datenstruktur kann erhalten werden durch Bezugnehmen auf die Flussdiagramme der 7, 9 und 10 sowie die detaillierten Beschreibungen die jenen Flussdiagrammen zugeordnet sind. Die lokale FCS 2520 enthält eine Statusfeld 2522, welches den gegenwärtigen Status der Datei als derzeit offen, derzeit geschlossen, oder in irgendeinem Zwischenzustand befindlich, repräsentiert, wenn Kommunikationen auftreten. Das Sequenznummernfeld 2524 wird vor den anfänglichen Kommunikationen für jeden Ferndateilese-, Schreib-, Öffnung-, Erzeugungs- oder Schließversuch geändert. Als solcher kann der Ferndatenwiederherstellungskommunikationsserver 68 ermitteln, ob solche Anfragen neue Anfragen oder Wiederholungen von Anfragen sind, für welche die Antwort aufgrund eines Kommunikationsfehlers verloren wurde. Die Wiederholungen werden auf einer Pro-Anfrage-Basis mit dem Wiederholungszählfeld 2526 gezählt, derart, dass eine beschränkte Anzahl von Wiederholungen versucht werden kann, bevor ein Ablauf abgebrochen wird. Das gegenwärtige Dateizeigerfeld 2528 wird verwendet, um ein Protokoll des Offset in der Datei, wie für Datenstromfunktionen verwendet, aufrecht zu erhalten. Um sich vor Anfragen oder Bestätigungen zu schützen, welche aufgrund von Kommunikationsfehlern verloren wurden, existiert ein Auszeitfeld 2530, um die Feststellung zu erlauben, ob ausreichend Echtzeit zwischen der Anfrage und einer beliebigen Antwort auf diese Anfrage verstrichend ist. Wann immer ausreichend Zeit verstrichen ist, wird angenommen, dass entweder die Anfrage oder die Antwort auf diese Anfrage verloren wurde.
  • Während der Dateilesehandlungen wird ein Leseanfragelistenpaket gesendet, um jene Dateisegmente anzufordern, welche gewünscht sind, jedoch noch nicht empfangen wurden. Dateien werden auf Basis von Segmenten, die Quantumeinheiten genannt werden, übertragen, wobei das Segment ein sequentielles Fragment fester Größe der Datei ist. Jedes beliebige Dateidatentransferpaket enthält höchstens ein Segment. Die feste Größe des Segments ist vom Programmierer vordefiniert wird basiert auf Rechenkomfort, Dateisystemleistung und unter Berücksichtigung der resultierenden Paketgröße. Die Anfrageliste wird mit einem anfänglichen Segmentwert erzeugt, der gleich ist dem nächsten zu empfangenden Segment 2532, und fordert so viele sequentielle Segmente wie möglich, ohne das Feld der gesamten übrigen zu empfangenden Segmente 2531 zu überschreiten. Alle beliebigen Segmente, welche außerhalb der Sequenz empfangen werden, werden verworfen und verursachen unmittelbar, dass eine überarbeitete Leseanfrageliste erzeugt und in der Übertragungswarteschleife bei Schritt 766 von 7 platziert wird. Auch jede beliebige Auszeitbedingung verursacht, dass eine überarbeitete Leseanfrageliste erzeugt und in der Übertragungswarteschleife bei Schritt 1030 von 10 platziert wird.
  • Während Dateischreibehandlungen wird ein Schreibeinitialisierungspaket gesendet, wobei das Schreibeinitialisierungspaket eine Startsegmentnummer und eine Gesamt-Bytezahl enthält. Dieses Paket erlaubt es dem Kommunikationsserver 68, Dateisegmente anzufordern, wenn die Puffer- und I/O Subsysteme des Kommunikationsservers bereit werden, Dateisegmente zu empfangen. Der Kommunikationsserver 68 stellt solche Anfragen nach Dateisegmenten durch Senden von Dateischreibeanfragelistenpaketen, welche bei Schritt 712 von 7 verarbeitet werden. Die Datenstrukturfelder Erstes Angefordertes Segment 2536 und Zahl Der Angeforderten Segmente 2538 werden direkt von dem Dateischreibeanfragelistenpaket genommen. Das/die Dateischreibedatenpaket(e) wird/werden dann in der Übertragungswarteschleife platziert. Das Feld Nächstes Zu Sendendes Segment 2540 wird verwendet, um zu ermitteln, mit welchem Dateisegment mit dem Platzieren in der Warteschleife begonnen wird. Solange das nächste zu sendende Segment innerhalb des Bereichs liegt, der von dem ersten angeforderten Segment und der Zahl der angeforderten Segmente beschrieben ist, wird angenommen, dass jede beliebige Differenz zwischen dem letzten zu sendenden Segment 2540 und dem ersten angeforderten Segment 2536 von Paketen herrührt, welche sich in Übertragung befinden. Der Empfang eines Dateischreibanfragelistenpakets mit einer Nullanfrage wird als erfolgreiche Fertigstellung der Dateischreibehandlung interpretiert.
  • Das Diagramm 2560 beschreibt Bildschirmzeilenänderungsdeskriptor- (Screen Line Change Descriptor, SLCD)Datenstrukturen, welche verwendet werden, um im Auge zu behalten, welche Teile des virtuellen Bildschirms, auf die von den RDR-Anwendungen 300 geschrieben wird, noch nicht erfolgreich an den RDR-Kommunikationsserver 68 übermittelt worden sind. Es existiert innerhalb des SLCD ein Paar von Feldern, die erste dreckige Spalte 2562 und die letzte dreckige Spalte 2564, für jede Zeile von Zeichen auf dem Bildschirm. Dieses Feldpaar beschreibt den einschließenden Bereich der Spalten, welche modifizierte jedoch noch nicht übertragene Daten enthalten.
  • 26 enthält beschreibende Zeichnungen weiterer Datenstrukturen, die in einer Ausführungsform der lokalen RDR-Anwendung 308 verwendet werden, sowie beschreibende Zeichnungen von Datenstrukturen, welche in einer Ausführungsform der RDR-Kommunikationsserveranwendung verwendet werden.
  • Die in 26 bei 2610 beschriebene Datenstruktur ist eine Paketempfangssteuerungs- (Packet Receive Control, PRC) Struktur. Die PRC wird verwendet von der lokalen RDR-Anwendung 308, um eingehende Pakete zu dekodieren, Statistiken zu pflegen und Steuerungen an. die Routinen von 7 zu übertragen, welche für die Handhabung jedes spezifischen Typs eingehender Pakete verantwortlich sind. Das Feld Zeigerlink Auf Nächste Paketempfangsstruktur 2612 wird verwendet, um eine Zusammenstellung solcher Strukturen in einer klassischen einfach verlinkten Liste zu pflegen. Das Pakettypnummernfeld 2614 wird gegen das Typfeld eingehender Pakete abgeglichen und ermittelt, ob dieses Paket gemäß dieser PRC oder einer darauffolgenden PRC gehandhabt werden soll. Wenn das Pakettypnummernfeld gleich dem Typfeld des eingehenden Pakets ist, wird das Paketzählerfeld 2616 erhöht, um Statistiken zu pflegen und die Softwareroutine, auf die von dem Zeiger Zu Paketsteuerungs programmroutine-Feld 2618 gezeigt wird, wird aufgerufen, um die Verarbeitung des eingehenden Pakets handzuhaben.
  • Die Datenstruktur 2620 ist die Dateisteuerungsstruktur (File Control Structure, FCS) wie innerhalb des RDR-Kommunikationsservers 68 verwendet. Eine Server-FCS 2620 existiert für jede potentiell gleichzeitige Instanz einer offenen Ferndatei innerhalb der RDR-Kommunikationssserveranwendung. Weiterer Einblick in die Verwendung dieser Datenstruktur kann erhalten werden durch Bezugnahme auf die Flussdiagramme der 18 und 19 sowie die detaillierten Beschreibungen, die mit jenen Flussdiagrammen verbunden sind. Die Server-FCS 2620 enthält ein Statusfeld 2622, welches den gegenwärtigen Status der Datei als gegenwärtig offen, gegenwärtig geschlossen oder in einem beliebigen Zwischenzustand befindlich, wenn Kommunikationen auftreten, repräsentiert. Das letzte Sequenznummernfeld 2620 wird nach jedem Ferndateilese-, Schreib-, Öffnung-, Erzeugungs- oder Schließ-Versuch überprüft. Als solche kann die RDR-Kommunikationsserveranwendung ermitteln, ob solche Anfragen neue Anfragen oder Wiederholungen von Anfragen sind, für welche die Antwort aufgrund eines Kommunikationsfehlers verloren wurde. Wiederholungen werden auf einer Pro-Anfrage-Basis mit dem Wiederholungszählerfeld 2626 gezählt, derart dass eine beschränkte Anzahl von Wiederholungen versucht werden kann, bevor ein Vorgang abgebrochen wird. Um sich gegen Anfragen oder Bestätigungen zu schützen, welche aufgrund von Kommunikationsfehlern verloren wurden, existiert ein Auszeitfeld 2630, um die Feststellung zu erlauben, ob genügend Echtzeit zwischen der Anfrage und einer beliebigen Antwort auf diese Anfrage verstrichen ist. Wann immer genügend Zeit verstrichen ist, wird dann angenommen, dass entweder die Anfrage oder die Antwort auf diese Anfrage verloren wurde. Wenn Dateien erzeugt oder geöffnet werden, wird das tatsächliche Dateihandhabungs-Feld 2636 verwendet, um das tatsächliche Dateihandle zu halten, das von dem System für die Referenzierung dieser Datei in zukünftigen Lese-, Schreib- oder Schließanfragen verwendet wird.
  • Währende der Lesevorgänge werden die Leseanfragelistenpakete beantwortet durch lediglich Ausführen des tatsächlichen Dateilesens, wie in der Anfrageliste spezifiziert und anschließendes Senden der angeforderten Dateidaten als Dateilesedatenpaket(e). Sollte ein Leseanfragelistenpaket ankommen, während Dateilesedatenpalcete gesendet werden, sollte angenommen werden, dass ein Paket aufgrund eines Kommunikationsfehlers verloren wurde und die vorhe rige Sequenz von Dateilesedaten sollte gestoppt werden und die neue Leseanfrageliste sollte anerkannt werden. Relevante Felder der FCS-Datenstruktur während der Lesevorgänge sind der Gegenwärtige Dateizeiger 2628, das Erste Angefragte Segment 2632, der Angefragte Segmentzähler 2634. Diese Felder werden von den Inhalten des Leseanfragelistenpakets gefüllt und werden angepasst, wenn die damit verbundenen Dateilesedatenpakete übertragen werden.
  • Während Dateischreibvorgängen werden Schreibdateiintitalisierungspakete empfangen, um den beabsichtigten Schreibvorgang zu definieren. Die Schreibdateiinitialisierungspakete stellen Informationen für die Felder Gegenwärtiger Dateizeiger 2628, Erstes Angefragtes Segment 2632, und Angefragter Segmentzähler 2634 der Server-FCS 2620 bereit. Zusätzlich wird Speicher pro Anfrage und in Berücksichtigung der Systemressourcenbenutzung zugewiesen. Die Zahl des Felds Freier Segmentpuffer 2636, des Felds Gesamtzahl An Segmenten 2640 und des Felds Zeiger Zu Segmentpuffer 2642 werden gesetzt, um die Zahl der zugewiesenen Segmentpuffer und deren Speicherort wiederzugeben. Wenn Schreibedateidatenpakete ankommen, werden diese in verfügbare Puffer platziert und für das Schreiben in die Datei eingeplant. Die Ankunft eines Dateisegments wird die Zahl der freien Segmentpuffer 2638 erniedrigen und das erfolgreiche Schreiben jener Segmente wird die Zahl der freien Segmentpuffer 2638 wiederum erhöhen. Dateischreibeanfragelistenpakete werden durch Verwenden des Felds Erste Segmentanfrage 2632 als eine Startsegmentnummer formuliert und die Zahl der angefragten Segmente wird entweder durch die Felder Zahl Der Freien Segmentpuffer 2638 oder Angeforderter Segmentzähler 2634 beschränkt. Die Felder Erstes Angefragtes Segment 2632 und Angefragter Segmentzähler 2634 werden jeweils erhöht und erniedrigt, wenn Dateidatenpakete ankommen, derart dass sie eine genaue Beschreibung der Dateidaten, die zum Empfang verbleiben, aufrecht erhalten.
  • Es wird verstanden werden, dass die vorliegende Erfindung viele Variationen der oben beschriebenen Ausführungsformen annehmen kann. Das Prinzip der vorliegenden Erfindung ist es, eine Diagnose von Datenspeichergeräten und/oder einer Datenwiederherstellung durch einen Ferndatenwiederherstellungscomputer zu erlauben. In manchen Fällen wird nur die Diagnose entfernt durchgeführt, da der Benutzer wählen kann, nicht mit der tatsächlichen Wiederherstellung fortzufahren. In manchen Fällen wird die Wiederherstellung auf dem lokalen Computer durchgeführt und die wiederhergestellten Daten auf dem Speichergerät 26 des lo kalen Benutzers wiederhergestellt. In vielen Fällen können die Daten auf die RDR netzwerkfreigegebenen Laufwerke 65 heruntergeladen, wiederhergestellt und auf ein neues Speichermedium gespeichert werden, welches dann an den Benutzer gesendet und/oder von dem Benutzer abgeholt wird. In manchen Fällen können beschädigte Daten auf die RDR netzwerkfreigegebenen Laufwerke 65 heruntergeladen, wiederhergestellt und dann zurück auf den lokalen RDR-Comupter 20 hochgeladen werden. Es wird verstanden werden, dass diese Szenarien nur einige der vielen Szenarien sind, die unter den Prinzipien der vorliegenden Erfindung auftreten können. Es kann erkannt werden, dass automatisiertes, detailliertes Protokollieren nennenswerter Ereignisse einschließlich Chat-Konversationen, die Akzeptanz von rechtlichen Übereinkommen, verwendeten Datenwiederherstellungsanwendungen etc. wertvoll in der Analyse von Geschäftstrends sowie als Referenzmaterial für jeden beliebigen Streit sein kann, welcher von Zeit zu Zeit auftreten kann. Deshalb würde die bevorzugte Ausführungsform der RDR Mittel für die Protokollierung von Ereignissen, wie beispielsweise die folgenden, enthalten:
    • 1. Verbindungsstart: Datum/Uhrzeit, Client Job-id und Telefonnummer, Kommunikationskanaltyp und Geschwindigkeit;
    • 2. Datenwiederherstellungsdiagnose-/Anwendungs-Programm-Start- und -Stop-Daten/Zeiten sowie sämtliche Berichte von den Programmen;
    • 3. Alle Chat- oder Dialognachrichten (in beide Richtungen);
    • 4. Alle übermittelten rechtlichen Übereinkommen, Client-Antwort auf die Übereinkommen, alle Anhänge oder Beilagen;
    • 5. Vollständige Protokolle aller Datensektoren, modifiziert und deren voriger Zustand; und
    • 6. Verbindungsbeendigungs-Datum/Zeit.
  • Es kann verstanden werden, dass das Leistungsverhalten der Datenwiederherstellung die Postulation einer Hypothese einbeziehen kann, welche sich als unangemessen erweisen kann, wenn der Wiederherstellungsprozess fortfährt. Deshalb ist es wünschenswert, die Möglichkeit zu erlauben, am lokalen Speichergerät 26 durchgeführte Modifikationen „rückgängig" zu machen, wenn anschließend ermittelt wird, dass solche Modifikationen auf unrichtigen Annahmen basiert haben oder anderweitig unpassend sind. In der bevorzugten Ausführungsform wird ein Mechanismus bereitgestellt, um alle Änderungen am lokalen Speichergerät zu verzögern bis zu solch einem Zeitpunkt, wenn der Bediener der RDR-Workstation die Entschei dung trifft, fortzufahren oder alternativ die Änderungen fallen zu lassen. Wenn die Entscheidung gefällt wurde, die Änderungen durchzuführen, dann werden alle Daten, welche dafür markiert sind, geändert zu werden, zuerst zu der RDR-Einrichtung für eine Archivierung übertragen. Nur dann werden die neuen Daten tatsächlich auf das lokale Speichergerät 26 geschrieben. Das bevorzugte Verfahren, solch einen Mechanismus zu implementieren, erfolgt mit einer Datei, welche sämtliche Schreibaktivitäten, welche auf dem lokalen Speichergerät 26 durchgeführt werden würden, protokolliert. Die Datei verbleibt auf dem Speichergerät 65, das mit dem Netzwerk verbunden ist, an der Ferndatenwiederherstellungsstelle. Jeder Eintrag innerhalb der Datei enthält einen Identifizierer, welche den eindeutigen Sektor und das lokale Speichergerät identifiziert, welches repräsentiert ist, sowie die neuesten Daten, welche auf diesen Sektor geschrieben wurden. Es ist effizienterweise ein „Write-Cache".
  • 27 ist ein Flussdiagramm des IO-Logic Layer innerhalb der lokalen RDR-Anwendung 308, welcher die Möglichkeit des „Rückgängigmachens" aller beliebigen Modifikationen, die an dem lokalen Datenspeichergerät 26 durchgeführt werden, implementiert. Alle Versuche, auf das lokale Speichergerät 26 zu schreiben, betreten diesen IO-Logic Layer bei 2710. Wenn der/die angeforderte(n) Sektoren) nicht zuvor beschrieben wurde(n), wird es keinen existierenden Eintrag in der Log-Datei geben. Wenn diese Bedingung ermittelt wird bei 2720, wird ein Log-Dateieintrag bei 2730 hinzugefügt werden und bei 2735 werden die zu schreibenden Daten in den Log-Dateieintrag geschrieben. Wenn bei 2720 ermitelt wird, dass der/die angeforderte(n) Sektoren) zuvor geschrieben wurde(n), wird der existierende Log-Dateieintrag bei 2740 mit den neuen zu schreibenden Daten aktualisiert. Es wird deshalb in dieser Log-Datei ein Eintrag für jeden Sektor, welcher währende der Datenwiederherstellungssitzung geschrieben wurde, existieren. Alle Versuche, das lokale Speichergerät 26 zu lesen, betreten diesen IO-Layer bei 2750. Wenn bei 2760 ermittelt wird, dass der/die angefragte(n) Sektoren) nicht in der Log-Datei existieren, d. h. sie wurden nicht während dieser Sitzung beschrieben, werden die Daten direkt von dem Gerät bei 2770 gelesen. Wenn bei 2760 ermittelt wird, dass der/die angeforderte(n) Sektoren) in der Log-Datei existieren, d. h. die Sektoren wurden während dieser Sitzung geschrieben, werden bei 2780 die Daten von der Log-Datei gelesen, um der Anfrage zu entsprechen. Dies gibt die Erscheinung an die Datenwiederherstellungsanwendungsprogramme 300, das die Sektoren in der Tat geschrieben werden, jedoch dieses Schreiben tatsächlich von der Log-Datei zwischengespeichert ist.
  • 28 ist ein Flussdiagramm der Anwendung, welche die Log-Dateien manipuliert, um den Abbruch von Änderungen, das Überlassen von neuen Daten und die potentielle Wiederherstellung von Originaldaten zu erleichtern. Sektoren, für welche entschieden wurde, dass sie unangemessen modifiziert worden sind, können „rückgängig gemacht" werden bei 2810 durch Entfernen der entsprechenden Log-Dateieinträge bei 2815. Wenn es wünschenswert wird, alle Modifikationen bei 2820 durchzuführen, werden die Originaldaten, die dabei sind, überschrieben zu werden, bei 2830 zu einer Datei auf dem netzwerkangebundenen Speichergerät 65 bei der Ferndatenwiederherstellungsstelle übertragen. Diese Originaldaten-Log-Datei wird dann bei 2840 archiviert. Zuletzt werden, da die Originaldaten nun sicher archiviert wurden, die Log-Dateidaten verwendet, um das lokale Speichergerät 26 bei 2850 zu modifizieren. Wenn, aus welchem Grund auch immer, es als angemessen gilt, das lokale Speichergerät 26 auf den Originalstatus wiederherzustellen, ist es möglich, alle durchgeführten Änderungen bei 2870 rückgängig zu machen. In diesem Fall werden die Originaldaten, welche bei 2830 und 2840 jeweils übertragen und archiviert wurden, zurück zum lokalen Computerspeicher bei 2880 übertragen und alle Sektoren, die so in dieser Originaldaten-Log-Datei notiert sind, werden bei 2885 zum lokalen Speichermedium 26 wiederhergestellt, wobei das lokale Speichergerät 26 in dessen Originalstatus belassen wird.
  • Es ist zu verstehen, dass, obwohl verschiedene Charakteristiken und Vorteile der Erfindung in der vorangehenden Beschreibung dargelegt wurden, zusammen mit Details der Struktur und Funktion der Erfindung, diese Offenbarung lediglich illustrativ ist und Änderungen im Detail durchgeführt werden können, insbesondere in Bezug auf die Form, Größe und Anordnung der Teile innerhalb des Prinzips der Erfindung zum vollen Ausmaß, welches durch die breite generelle Bedeutung der Ausdrücke angegeben ist, in welchen die angehängten Ansprüche formuliert sind.

Claims (16)

  1. Verfahren zur Fernwiederherstellung von Daten von einem Speichermedium in einem lokalen Computer mit einem normalen Betriebssystem, dadurch gekennzeichnet, dass es folgende Schritte umfasst: – laden eines Wechselspeichermediums in ein Wechselspeichermediengerät des lokalen Computers, wobei das Wechselspeichermedium ein boot-fähiges, im Voraus dort aufgespieltes Datenfernwiederherstellungsbetriebsprogramm enthält; – laden des boot-fähigen Datenfernwiederherstellungsbetriebsprogramms vom Wechselspeichermedium in den Speicher des lokalen Computers, wobei das boot-fähige Datenfernwiederherstellungsbetriebsprogramm lokal von dem lokalen Computer und unabhängig vom normalen Betriebssystem betrieben wird; – ausbauen von Kommunikationen zwischen dem lokalen Computer und einem entfernten Datenwiederherstellungscomputer durch Betrieb des Datenfernwiederherstellungsbetriebsprogramm durch den lokalen Computer; und – fernsteuern des lokalen Computers durch den entfernten Datenwiederherstellungscomputer, worauf Daten auf dem Speichermedium des lokalen Computers durch Betrieb des entfernten Datenwiederherstellungscomputers untersucht und wiederhergestellt werden können.
  2. Verfahren gemäß Anspruch 1, weiterhin folgenden Schritt umfassend: – abfragen eines lokalen Computerbenutzers nach Informationen durch betreiben des Datenfernwiederherstellungsbetriebsprogramms durch den lokalen Com puter bevor mit dem entfernten Datenwiederherstellungscomputer Kommunikation aufgebaut wird.
  3. Verfahren gemäß Anspruch 2, weiterhin umfassend die Schritte: – abfragen des lokalen Computerbenutzers nach Datenwiederherstellungsinformationen durch betreiben des Datenfernwiederherstellungsbetriebsprogrammes durch den lokalen Computer bevor mit dem entfernten Datenwiederherstellungscomputer Kommunikation aufgebaut wird; und – abfragen des lokalen Computerbenutzers nach Benutzeridentifizierungsinformationen durch betreiben des Datenferwiederherstellungsbetriebsprogrammes durch den lokalen Computer bevor mit dem entfernten Datenwiederherstellungscomputer Kommunikation aufgebaut wird; und
  4. Verfahren gemäß Anspruch 1 weiterhin umfassend den Schritt: – überwachen des Betriebs von Datenwiederherstellungsprogrammen, die auf dem lokalen Computer ausgeführt werden, mittels einer Anzeige am entfernten Datenwiederherstellungscomputer.
  5. Verfahren gemäß Anspruch 1, weiterhin umfassend den Schritt: – steuern der Erscheinung einer lokalen Anzeige auf dem lokalen Computer durch den entfernten Datenwiederherstellungscomputer.
  6. Verfahren gemäß Anspruch 1, weiterhin umfassend den Schritt: – herunterladen eines Datenwiederherstellungsprogrammes vom entfernten Datenwiederherstellungscomputer auf den lokalen Computer.
  7. Verfahren gemäß Anspruch 1, weiterhin umfassend den Schritt: – ausführen eines Datenwiederherstellungsanwendungsprogrammes auf dem lokalen Computer.
  8. Verfahren gemäß Anspruch 1, weiterhin umfassend den Schritt: – herunterladen von wiederherzustellenden Daten vom lokalen Computer auf den entfernten Datenwiederherstellungscomputer.
  9. Verfahren gemäß Anspruch 1, weiterhin umfassend die Schritte: – herunterladen eines Datenwiederherstellungsanwendungsprogrammes vom entfernten Datenwiederherstellungscomputer auf den lokalen Computer und ausführen des Datenwiederherstellungsanwendungsprogrammes.
  10. Verfahren gemäß Anspruch 1, weiterhin umfassend den Schritt: – zurückstellen von Datenänderungen auf den lokalen Computer bis zu einer Zeit, zu der ein Bediener des entfernten Datenwiederherstellungscomputers die Entscheidung über ein Fortsetzen oder, alternativ, über das Abbrechen der Datenänderungen trifft.
  11. Verfahren gemäß Anspruch 10, weiterhin umfassend die Schritte: wobei falls eine Entscheidung zugunsten der Datenänderungen an den lokalen Computer erfolgt, alle Daten, die als zu ändern gekennzeichnet sind, zunächst an eine Archivierungseinrichtung beim entfernten Datenwiederherstellungscomputer zwecks Archivierung übersendet werden; – protokollieren aller Schreibaktivitäten, die auf einem Sektor eines lokalen Speichergeräts des lokalen Computers ausgeführt werden, in einer Datei auf dem entfernten Datenwiederherstelllungscomputer; und – bereitstellen eines Identifizierers für jeden Eintrag in der Datei, welcher den Sektor und das lokale Speichergerät, sowie die neuesten, in diesem Sektor geschriebenen Daten identifiziert.
  12. Computerprogrammprodukt umfassend Computerprogrammcodemittel zur Ausführung der Schritte von einem beliebigen der Verfahrensansprüche 1–11, wenn das Computerprodukt auf einem Computer ausgeführt wird.
  13. Moduliertes Datensignal mit darauf verkörperten computerausführbaren Anweisungen zur Ausführung der Schritte von einem beliebigen der Verfahrensansprüche 1–11, wenn das Datensignal auf einem Computer eingesetzt wird.
  14. Datenwiederherstellungssystem zur Wiederherstellung von unzugänglichen Daten von einem Datenspeichermedium, umfassend: – einen lokalen, dem Datenspeichermedium zugeordneten Computer, wobei der lokale Computer eine zentrale Verarbeitungseinheit, Speicher, ein Wechselmedienspeichergerät und ein normales Betriebssystem aufweist; – einen entfernten Datenwiederherstellungscomputer; – gekennzeichnet durch: ein Wechseldatenspeichermedium zum laden in das Wechselspeichermediengerät des lokalen Computers, wobei das Wechseldatenspeichermedium darauf aufgenommene boot-fähige Datenwiederherstellungsprogrammmittel umfaßt; und – boot-fähige entfernte Datenwiederherstellungsprogrammmittel zum laden in den Speicher des lokalen Computers für den Betrieb des lokalen Computers unabhängig vom normalen Betriebssystem und zum Ausbauen vom Kommunikationen zwischen dem lokalen Computer und dem entfernten Datenwiederherstellungscomputer; – wobei der lokale Computer vom entfernten Datenwiederherstellungscomputer ferngesteuert wird, so dass Daten auf dem Datenspeichermedium des lokalen Computers diagnostiziert und wiederhergestellt werden können.
  15. Datenwiederherstellungssystem gemäß Anspruch 14, weiterhin umfassend einen Kommunikationskanal über welchen Kommunikationen aufgebaut werden zwischen dem lokalen Computer und dem entfernten Datenwiederherstellungscomputer, wobei der Kommunikationskanal eines aus einer Gruppe, bestehend aus einer Telefonleitung, einem lokalen Netz (LAN), Weitverkehrsübertragungsstrecken (WAN) und Internet, benutzt.
  16. Datenwiederherstellungssystem gemäß Anspruch 14 wobei das entfernte Datenwiederherstellungsprogrammmittel es dem lokalen Computer erlaubt, durch den entfernten Datenwiederherstellungscomputer ferngesteuert zu werden zwecks Wiederherstellung von Daten vom Datenspeichermedium.
DE69728178T 1996-06-18 1997-06-18 Vorrichtung und verfahren zur fernen datenrückgewinnung Expired - Lifetime DE69728178T2 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US66795696A 1996-06-18 1996-06-18
US667956 1996-06-18
US08/877,125 US6145088A (en) 1996-06-18 1997-06-17 Apparatus and method for remote data recovery
US877125 1997-06-17
PCT/US1997/010327 WO1997049056A2 (en) 1996-06-18 1997-06-18 Apparatus and method for remote data recovery

Publications (2)

Publication Number Publication Date
DE69728178D1 DE69728178D1 (de) 2004-04-22
DE69728178T2 true DE69728178T2 (de) 2005-03-10

Family

ID=27099802

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69728178T Expired - Lifetime DE69728178T2 (de) 1996-06-18 1997-06-18 Vorrichtung und verfahren zur fernen datenrückgewinnung

Country Status (9)

Country Link
US (1) US6826707B1 (de)
EP (1) EP0980550B1 (de)
JP (1) JP4616423B2 (de)
AT (1) ATE262195T1 (de)
AU (1) AU716035B2 (de)
CA (1) CA2258798C (de)
DE (1) DE69728178T2 (de)
ES (1) ES2218688T3 (de)
WO (1) WO1997049056A2 (de)

Families Citing this family (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100342023B1 (ko) * 1999-10-12 2002-06-27 이채홍 원격 조정 데이터 복원 시스템 및 이를 이용한 데이터 복원 방법
GB2363482B (en) * 2000-06-15 2003-01-15 Yair Zadik Remote control unit
KR20020032786A (ko) * 2000-10-27 2002-05-04 이채홍 온라인 데이터 복구 서비스 방법 및 시스템
JP2003140918A (ja) * 2001-10-29 2003-05-16 Fujitsu Ltd コンピュータの障害復旧支援装置及び方法、並びに、コンピュータの障害復旧支援プログラム
US8312117B1 (en) * 2001-11-15 2012-11-13 Unisys Corporation Dialog recovery in a distributed computer system
US7231643B1 (en) 2002-02-22 2007-06-12 Lexar Media, Inc. Image rescue system including direct communication between an application program and a device driver
AU2003216316A1 (en) * 2002-02-22 2003-09-09 Lexar Media, Inc. Image rescue
US6968477B2 (en) * 2002-03-07 2005-11-22 International Business Machines Corporation System and method for system surveillance using firmware progress code
JP3980421B2 (ja) * 2002-06-27 2007-09-26 富士通株式会社 プレゼンス管理方法及び装置
US7657779B2 (en) * 2002-09-18 2010-02-02 International Business Machines Corporation Client assisted autonomic computing
US7200775B1 (en) 2002-10-04 2007-04-03 American Megatrends, Inc. Method and data structures for use in providing on-demand computer diagnostics
US7334166B1 (en) 2002-10-04 2008-02-19 American Megatrends, Inc. Method, system, and apparatus for providing and utilizing server-side entry points for use in diagnostics on-demand services
US7231549B1 (en) * 2002-10-04 2007-06-12 American Megatrends, Inc. Method and apparatus for providing on-demand computer diagnostics
US20050010650A1 (en) * 2003-07-11 2005-01-13 Ying-Chuan Tsai Network-based computer platform external access method and system
US7454606B2 (en) * 2005-05-26 2008-11-18 Incharge Technology, Inc. Maintenance device for remotely accessing and repairing failed computer systems
US7558560B2 (en) * 2005-12-15 2009-07-07 Motorola, Inc. System and method for initiating communications between mobile stations
WO2007087194A2 (en) 2006-01-20 2007-08-02 Glenbrook Associates, Inc. System and method for the automated processing of physical objects
US7426616B2 (en) * 2006-08-22 2008-09-16 Hewlett-Packard Development Company, L.P. Method for determining a recovery schedule
US20080168310A1 (en) 2007-01-05 2008-07-10 Microsoft Corporation Hardware diagnostics and software recovery on headless server appliances
US20080307102A1 (en) * 2007-06-08 2008-12-11 Galloway Curtis C Techniques for communicating data between a host device and an intermittently attached mobile device
CA2593169A1 (en) * 2007-07-06 2009-01-06 Tugboat Enterprises Ltd. System and method for computer data recovery
US9990674B1 (en) 2007-12-14 2018-06-05 Consumerinfo.Com, Inc. Card registry systems and methods
US8850569B1 (en) * 2008-04-15 2014-09-30 Trend Micro, Inc. Instant messaging malware protection
US8312033B1 (en) 2008-06-26 2012-11-13 Experian Marketing Solutions, Inc. Systems and methods for providing an integrated identifier
WO2010002407A1 (en) * 2008-07-02 2010-01-07 Hewlett-Packard Development Company, L.P. Performing administrative tasks associated with a network-attached storage system at a client
US8060424B2 (en) 2008-11-05 2011-11-15 Consumerinfo.Com, Inc. On-line method and system for monitoring and reporting unused available credit
US8140906B1 (en) * 2008-12-29 2012-03-20 Symantec Corporation Techniques for recovering data from cold images
US9081735B2 (en) * 2011-02-12 2015-07-14 International Business Machines Corporation Collaborative information source recovery
US8707086B2 (en) * 2011-04-21 2014-04-22 Intel Corporation System recovery using external communication device
US9483606B1 (en) 2011-07-08 2016-11-01 Consumerinfo.Com, Inc. Lifescore
US9106691B1 (en) 2011-09-16 2015-08-11 Consumerinfo.Com, Inc. Systems and methods of identity protection and management
US8738516B1 (en) 2011-10-13 2014-05-27 Consumerinfo.Com, Inc. Debt services candidate locator
US9853959B1 (en) 2012-05-07 2017-12-26 Consumerinfo.Com, Inc. Storage and maintenance of personal data
US9654541B1 (en) 2012-11-12 2017-05-16 Consumerinfo.Com, Inc. Aggregating user web browsing data
US9916621B1 (en) 2012-11-30 2018-03-13 Consumerinfo.Com, Inc. Presentation of credit score factors
US9525607B2 (en) 2013-01-16 2016-12-20 Hewlett-Packard Development Company, L.P. Connectivity notification
US9406085B1 (en) 2013-03-14 2016-08-02 Consumerinfo.Com, Inc. System and methods for credit dispute processing, resolution, and reporting
US10102570B1 (en) 2013-03-14 2018-10-16 Consumerinfo.Com, Inc. Account vulnerability alerts
US10685398B1 (en) 2013-04-23 2020-06-16 Consumerinfo.Com, Inc. Presenting credit score information
US9477737B1 (en) 2013-11-20 2016-10-25 Consumerinfo.Com, Inc. Systems and user interfaces for dynamic access of multiple remote databases and synchronization of data based on user rules
CN109844717B (zh) * 2016-08-14 2023-05-23 利维帕尔森有限公司 用于移动应用程序的实时远程控制的系统和方法
US10409653B2 (en) 2016-12-27 2019-09-10 Dropbox, Inc. Kernel event triggers
US10331623B2 (en) 2017-10-16 2019-06-25 Dropbox, Inc. Workflow functions of content management system enforced by client device
US10880313B2 (en) 2018-09-05 2020-12-29 Consumerinfo.Com, Inc. Database platform for realtime updating of user data from third party sources
US11315179B1 (en) 2018-11-16 2022-04-26 Consumerinfo.Com, Inc. Methods and apparatuses for customized card recommendations
US11238656B1 (en) 2019-02-22 2022-02-01 Consumerinfo.Com, Inc. System and method for an augmented reality experience via an artificial intelligence bot
US11941065B1 (en) 2019-09-13 2024-03-26 Experian Information Solutions, Inc. Single identifier platform for storing entity data

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4463418A (en) * 1981-06-30 1984-07-31 International Business Machines Corporation Error correction from remote data processor by communication and reconstruction of processor status storage disk
US4589090A (en) 1982-09-21 1986-05-13 Xerox Corporation Remote processor crash recovery
JP2570725B2 (ja) 1987-03-06 1997-01-16 日本電気株式会社 リモ−ト診断装置
JPH0644242B2 (ja) * 1988-03-17 1994-06-08 インターナショナル・ビジネス・マシーンズ・コーポレーション コンピュータ・システムにおける問題解決方法
US5133065A (en) * 1989-07-27 1992-07-21 Personal Computer Peripherals Corporation Backup computer program for networks
US5412801A (en) 1990-01-17 1995-05-02 E-Net Gap recovery for off-site data storage and recovery systems
US5388252A (en) 1990-09-07 1995-02-07 Eastman Kodak Company System for transparent monitoring of processors in a network with display of screen images at a remote station for diagnosis by technical support personnel
FR2682786B1 (fr) 1991-10-17 1993-12-10 Bull Sa Telechargement d'un systeme d'exploitation par un reseau.
US5367667A (en) 1992-09-25 1994-11-22 Compaq Computer Corporation System for performing remote computer system diagnostic tests
US5732212A (en) * 1992-10-23 1998-03-24 Fox Network Systems, Inc. System and method for remote monitoring and operation of personal computers
GB2273180A (en) 1992-12-02 1994-06-08 Ibm Database backup and recovery.
US5455933A (en) * 1993-07-14 1995-10-03 Dell Usa, L.P. Circuit and method for remote diagnosis of personal computers
JPH07319747A (ja) * 1994-05-24 1995-12-08 Nec Telecom Syst Ltd データ更新システム
GB9422854D0 (en) 1994-11-12 1995-01-04 Int Computers Ltd High availability data processing system
US5727142A (en) * 1996-05-03 1998-03-10 International Business Machines Corporation Method for a non-disruptive host connection switch after detection of an error condition or during a host outage or failure
US5673382A (en) 1996-05-30 1997-09-30 International Business Machines Corporation Automated management of off-site storage volumes for disaster recovery

Also Published As

Publication number Publication date
JP4616423B2 (ja) 2011-01-19
AU3393397A (en) 1998-01-07
CA2258798C (en) 2009-12-22
WO1997049056A2 (en) 1997-12-24
AU716035B2 (en) 2000-02-17
CA2258798A1 (en) 1997-12-24
ES2218688T3 (es) 2004-11-16
WO1997049056A3 (en) 1998-10-29
US6826707B1 (en) 2004-11-30
EP0980550A2 (de) 2000-02-23
JP2000517074A (ja) 2000-12-19
EP0980550B1 (de) 2004-03-17
ATE262195T1 (de) 2004-04-15
DE69728178D1 (de) 2004-04-22

Similar Documents

Publication Publication Date Title
DE69728178T2 (de) Vorrichtung und verfahren zur fernen datenrückgewinnung
DE60025488T2 (de) Vorrichtung und verfahren zur allgemeinen koordination und verwaltung von mehrfachen schnappschussanbietern
DE69938077T2 (de) Verfahren, Vorrichtung und Programmspeichereinrichtung für einen Klienten und ein adaptiver Synchronisierungs- und Transformierungsserver
DE69329743T9 (de) Computerverwaltungssystem und entsprechende Datenbank für Verwaltungsinformationen
DE3908459C2 (de) Netzwerkserver
US6145088A (en) Apparatus and method for remote data recovery
AU640029B2 (en) Distributed data processing systems
US5933601A (en) Method for systems management of object-based computer networks
DE69936627T2 (de) In einer warteschlange angeordnete aufrufe von prozeduren für verteilte auf komponenten basierte anwendungen
DE60133648T2 (de) System und verfahren zum führen von laufzeitdaten in einem server-netzwerk
DE69735917T2 (de) Flexibler SNMP trap Mechanismus
DE602005002679T2 (de) WEB-Dienst-Anwendungsprotokoll und SOAP-Verarbeitungsmodell
DE10112941B4 (de) System und Verfahren für das parallele Lesen von primären und sekundären Sicherungen zur Wiederherstellung mehrerer gemeinsam benutzter Datenbankdateien
DE60035830T2 (de) Netzwerkgeräteverwaltungsvorrichtung und - verfahren
DE602004002858T2 (de) Vorrichtung und Verfahren zur Datenarchivierung in einem Clustersystem
DE60018803T2 (de) Verfahren und apparat zur verwaltung von information der speicheraktivitäten von datenspeichersystemen
DE60023349T2 (de) System, Verfahren und Rechnerprogrammprodukt zur Überwachung des Gebrauchs einer Zielanwendung
DE60025043T2 (de) Vorrichtung und verfahren mit verwendung von anwendungabhängigkeitsinformation für eine sicherungskopieherstellung in einem computersystem
DE69733305T2 (de) System/Verfahren zur wirkungsvollen Übermittlung von Datenströmen in einem Multimediasystem
DE10225664A1 (de) System und Verfahren zum Prüfen von Systemabrufereignissen mit Systemabrufumhüllungen
WO1997049056A9 (en) Apparatus and method for remote data recovery
DE10128883A1 (de) Verfahren und System für die Verteilung von Anwendungsdaten auf verteilte Datenbanken mit verschiedenen Formaten
US20020194320A1 (en) Remote support system
DE10337144A1 (de) Verfahren zur Aufzeichnung von Ereignis-Logs
DE69830226T2 (de) Netzwerkkommunikationsbenutzernachrichtenübertragungssystem

Legal Events

Date Code Title Description
8332 No legal effect for de
8370 Indication related to discontinuation of the patent is to be deleted
8364 No opposition during term of opposition