DE112016000176T5 - Datendeduplizierung unter Verwendung von Chunk-Dateien - Google Patents

Datendeduplizierung unter Verwendung von Chunk-Dateien Download PDF

Info

Publication number
DE112016000176T5
DE112016000176T5 DE112016000176.2T DE112016000176T DE112016000176T5 DE 112016000176 T5 DE112016000176 T5 DE 112016000176T5 DE 112016000176 T DE112016000176 T DE 112016000176T DE 112016000176 T5 DE112016000176 T5 DE 112016000176T5
Authority
DE
Germany
Prior art keywords
file
chunk
computing system
files
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112016000176.2T
Other languages
English (en)
Inventor
Michael A. Dolan
Linh Kochan
Tamir Ram
Sean Rohr
Kent Tu
Shawn Miller
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.)
Western Digital Technologies Inc
Original Assignee
Western Digital Technologies 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
Application filed by Western Digital Technologies Inc filed Critical Western Digital Technologies Inc
Publication of DE112016000176T5 publication Critical patent/DE112016000176T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G06F11/1451—Management of the data involved in backup or backup restore by selection of backup contents
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G06F11/1453—Management of the data involved in backup or backup restore using de-duplication of the data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1469—Backup restoration techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0608—Saving storage space on storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0614—Improving the reliability of storage systems
    • G06F3/0619—Improving the reliability of storage systems in relation to data integrity, e.g. data losses, bit errors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/064—Management of blocks
    • G06F3/0641—De-duplication techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0646—Horizontal data movement in storage systems, i.e. moving data in between storage devices or systems
    • G06F3/065—Replication mechanisms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0683—Plurality of storage devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0683—Plurality of storage devices
    • G06F3/0688—Non-volatile semiconductor memory arrays
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/80—Database-specific techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/84—Using snapshots, i.e. a logical point-in-time copy of the data

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Quality & Reliability (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Retry When Errors Occur (AREA)

Abstract

Es werden Systeme und Verfahren zum Durchführen eines Datei-Backup und Wiederherstellen in einem Rechensystem offenbart. Gewisse Ausführungsformen stellen eine Kommunikationsschnittstelle bereit zum Kommunizieren mit einem nichtflüchtigen Speicher und einem Controller, der konfiguriert ist zum Bestimmen, dass eine in dem nichtflüchtigen Speicher abgelegte Datei modifiziert worden ist, Identifizieren eines Chunks der Datei, der modifiziert worden ist, Bestimmen eines mit dem modifizierten Chunk assoziierten neuen Chunks, wobei der neue Chunk die Modifikation widerspiegelt, Generieren einer separaten Chunk-Datei mit dem neuen Chunk und einem Dateinamen, und Speichern der Chunk-Datei in dem nichtflüchtigen Speicher unter Verwendung der Kommunikationsschnittstelle.

Description

  • ALLGEMEINER STAND DER TECHNIK
  • In Computersystemen kann ein Backup von Daten in einem Backup-Datenspeicher für eine Datenredundanz sorgen, die das Wiederherstellen von Daten nach einem Datenverlustereignis gestattet.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Verschiedene Ausführungsformen sind zu Veranschaulichungszwecken in den beiliegenden Zeichnungen dargestellt und sollten auf keinerlei Weise als den Schutzbereich der vorliegenden Offenbarung beschränkend ausgelegt werden. Außerdem können verschiedene Merkmale von verschiedenen offenbarten Ausführungsformen kombiniert werden, um zusätzliche Ausführungsformen auszubilden, die Teil der vorliegenden Offenbarung sind.
  • 1 ist ein Blockdiagramm eines Rechensystems gemäß einer oder mehreren Ausführungsformen.
  • 2A ist ein Blockdiagramm, das einen Daten-Blob mit mehreren Dateien gemäß einer oder mehreren Ausführungsformen darstellt.
  • 2B ist ein Blockdiagramm, das eine Datendatei mit mehreren Chunks von Daten gemäß einer oder mehreren Ausführungsformen darstellt.
  • 3A ist ein Blockdiagramm, das eine individuelle Chunk-Datei gemäß einer oder mehreren Ausführungsformen darstellt.
  • 3B ist ein Blockdiagramm, das eine Chunk-Datei gemäß einer oder mehreren Ausführungsformen darstellt.
  • 4 ist ein Blockdiagramm, das eine Dateiverzeichnishierarchie gemäß einer oder mehreren Ausführungsformen darstellt.
  • 5 ist ein Flussdiagramm, das einen Prozess zum Sichern einer Datei gemäß einer oder mehreren Ausführungsformen darstellt.
  • 6 ist ein Flussdiagramm, das einen Prozess zum Wiederherstellen einer Datei aus einem Backup-Speicher gemäß einer oder mehreren Ausführungsformen darstellt.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Wenngleich gewisse Ausführungsformen beschrieben werden, werden diese Ausführungsformen lediglich als Beispiel vorgelegt und sollen den Schutzbereich nicht beschränken. Tatsächlich können die hierin beschriebenen neuartigen Verfahren und Systeme in einer Vielzahl anderer Formen verkörpert werden. Zudem können verschiedene Weglassungen, Substitutionen und Änderungen an der Form der hierin beschriebenen Verfahren und Systeme vorgenommen werden, ohne von dem Schutzbereich abzuweichen.
  • Die hier verwendeten Überschriften dienen lediglich der Zweckmäßigkeit und beeinflussen den Schutzbereich oder die Bedeutung der Ansprüche nicht notwendigerweise. Es werden hier beispielhafte Konfigurationen und Ausführungsformen bezüglich des Sicherns von Daten in einem Rechensystem offenbart.
  • Überblick
  • Gemäß verschiedenen Datendeduplizierungsprozessen beinhaltet das Sichern von Daten das Aufteilen von Dateien in kleinere Chunks von Daten und, um Raum und/oder Datentransferzeit einzusparen, nur das Speichern jener Chunks, die sich während des Backup geändert haben. Bei gewissen Ausführungsformen wird ein Hash-Wert für jeden hashbaren Chunk einer Datei berechnet, so dass die geänderten Chunks durch Vergleichen von Hash-Werten und Identifizieren von Chunks, die damit assoziierte geänderte Hash-Werte besitzen, identifiziert werden können. Ein derartiger Prozess kann eine Anzahl von Vorzügen bereitstellen. Falls sich beispielsweise ein Chunk nicht geändert hat, wird ein derartiger Chunk nicht gespeichert, wodurch Datenablageressourcen eingespart werden. Falls außerdem ein Hash-Wert für einen bestimmten Chunk in einer Datei in einer anderen Datei gefunden wird, kann ein derartiger Chunk für die zweite und/oder nachfolgende Dateien wiederverwendet werden; der redundante Chunk wird nicht wieder gespeichert, und ein entsprechender Eintrag in einer Metadatenliste von Hash-Werten für diese Datei wird stattdessen aktualisiert, um die Beziehung wiederzugeben.
  • Bei containerisiertem Backup sorgen gewisse Lösungen für modifizierte oder neue Chunks, die mit einer an eine umfangreiche Datei anzuhängenden Datei assoziiert sind, oder einen Blob, wobei die umfangreiche Datei bzw. der umfangreiche Blob ständig so erweitert wird, dass sie/er die modifizierten/neuen Chunks enthalten. Gewisse Backup-Systeme gestatten jedoch möglicherweise nicht das Anhängen von Chunks an Dateien/Blobs innerhalb des Backup-Systems, oder eine derartige Operation ist möglicherweise ungünstig oder unpraktisch. Beispielsweise stellt ein Backup-Server möglicherweise keine öffentlich zugängliche Applikationsprogrammierschnittstelle (API) bereit, die es einem Client-System gestatten würde, das Speichern modifizierter/neuer Chunks in dem Backup-Server zu bewirken, ohne die ganze relevante Datei zuerst zu dem Client herunterzuladen. Deshalb kann es bei derartigen Systemen notwendig sein, eine Datei von dem Backup-System herunterzuziehen, modifizierte/neue Chunks daran anzuhängen und die ganze Datei/ den ganzen Blob mit den angehängten Chunks zurück zum Backup-System zu schieben, was verschiedene Datentransferineffizienzen einführen kann.
  • Gewisse hierin offenbarte Ausführungsformen sorgen für eine verbesserte Backup-Effizienz in Systemen, die möglicherweise das angehängte Schreiben von Chunks durch Generieren unabhängiger Dateien für jeden zu sichernden modifizierten/neuen Chunk gestatten. Bei gewissen Ausführungsformen sind eindeutige Datei-Chunks mit eindeutigen Hash-Werten assoziiert, die eine Abbildungsinformation liefern, die anzeigt, wo sich die Chunk-Datei in einer nichtflüchtigen Ablage des Backup-Systems befindet. Mit in der Backup-Datenspeicher gespeicherten individuellen Chunk-Dateien besteht möglicherweise keine Notwendigkeit, neue Chunks an einen einzelnen Blob oder eine andere umfangreiche Datenstruktur anzuhängen.
  • Datenablagesystem
  • 1 ist ein Blockdiagramm eines Rechensystems 100 mit einem Datenablage-Backup-System 120 und einem über eine Schnittstelle 175 kommunikativ an das Backup-System gekoppelten Host-System 110. Die Schnittstelle 175 kann eine verdrahtete oder drahtlose Schnittstellenverbindung oder irgendeine andere Art von Kommunikationsschnittstelle sein wie etwa beispielsweise SATA, USB, Thunderbolt, Ethernet, Wi-Fi, Bluetooth, PCIe oder dergleichen.
  • Das Host-System 110 kann eine oder mehrere Recheneinrichtungen mit einem oder mehreren Prozessoren sein, die zum Ausführen von Code konfiguriert sind. Der Host 110 kann weiterhin ein oder mehrere Datenablagemodule umfassen, wie etwa die in 1 dargestellte Hostdatenablage-Datenspeicher. Bei gewissen Ausführungsformen kann der Host 110 Daten in dem Host-Datenspeicher 114 ablegen.
  • Es kann für das Host-System 110 wünschenswert sein, eine Datenredundanz durch Sichern von Benutzerdaten zu dem Backup-System 120 zu implementieren, um das Risiko des Datenverlustes zu reduzieren oder aus anderen Gründen. Der Host 110 kann konfiguriert sein zum Sichern mindestens eines Teils der in dem Host-Datenspeicher 114 abgelegten Daten in einem oder mehreren externen Backup-Systemen einschließlich dem Backup-System 120. Das Backup-System 120 kann konfiguriert sein zum Empfangen von Daten von dem Host-System 110 über die Schnittstelle 175 und Sichern solcher Daten in einem oder mehreren nichtflüchtigen Ablagemodulen 140, wie durch einen Backup-Client angewiesen. Das dargestellte System 100 zeigt einen innerhalb eines Controllers 130 des Backup-Systems 120 implementierten Backup-Client 132. Alternativ oder zusätzlich kann das System 100 konfiguriert sein zum Implementieren eines Daten-Backups, wie durch einen Backup-Client 112 angewiesen, der eine Komponente des Host-Systems 110 ist. Bei gewissen, unten beschriebenen Ausführungsformen werden Backup-Operationen vorteilhafterweise durch den Backup-Client 112 des Host-Systems 110 angewiesen. Es versteht sich jedoch, dass sich die Backup-Client-Logik innerhalb des Schutzbereichs der vorliegenden Offenbarung an einem beliebigen gewünschten oder praktischen Ort befinden kann.
  • Bei gewissen Ausführungsformen umfasst das Backup-System 120 eine Direct-Attached-Ablageeinrichtung (DAS). Alternativ kann das Backup-System 120 ein über ein Computernetzwerk wie etwa das Internet an das Host-System 110 gekoppeltes abgesetztes Backup-Server-System sein.
  • Der Backup-Client 112 des Host-Systems 110 kann Lese- und/oder Schreibbefehle an das Backup-System 120 ausgeben, die das Backup-System anweisen, Kopien von Daten in der nichtflüchtigen Ablage 140 des Backup-Systems 120 zu speichern. Bei gewissen Ausführungsformen führt das Backup-System 120 weiterhin gewisse Metadatentabellen oder ein anderes datenerleichterndes effizientes Backup und Wartung von Benutzerdaten in der nichtflüchtigen Ablage 140.
  • Die Backup-Client-Logik kann konfiguriert sein zum Implementieren einer Datendeduplizierung, was das Identifizieren und Entfernen oder das Verhindern einer Duplizierung von Daten innerhalb der Datenablage 140 beinhalten kann, ohne die Datentreue und/oder -integrität zu beeinträchtigen. Die Deduplizierung kann während Hardwarefehlern Resilienz bereitstellen und kann weiterhin eine Prüfsummenvalidierung an Daten und Metadaten sowie Redundanz für Metadaten und Chunk-Daten (z.B. Daten-Chunks, auf die häufig zugegriffen wird) bereitstellen.
  • Um die Deduplizierungsfunktionalität zu erleichtern, kann der Backup-Client (132 und/oder 112) Dateien in kleinere Chunks (z.B. 32–128 kB) segmentieren, die bei gewissen Ausführungsformen von variabler Größe sein können. Der Backup-Client identifiziert weiterhin doppelte Chunks und führt eine einzelne Kopie jedes Chunks. Redundante Kopien der Chunks können durch Bezugnahmen auf die einzelne Kopie ersetzt werden, wie etwa in einer oder mehreren Metadatentabellen beschriebene Referenzen. Bei gewissen Ausführungsformen werden Chunks komprimiert und dann in Containerdateien für ein containerisiertes Backup organisiert.
  • Der Ausdruck „Chunk“ wird hierin gemäß seiner breiten und gewöhnlichen Bedeutung verwendet und kann sich auf eine beliebige Zuordnung oder Sammlung von Daten in einer beliebigen Art der Form oder Struktur beziehen. Zudem können Bezugnahmen auf „Chunks“ hierin auf eine beliebige Art von Datenstruktur anwendbar sein, wie etwa Chunks, Heaps, Blobs, Dateien, Blöcke, Seiten oder eine andere Datenstruktur. Hierin beschriebene Chunks können von fester oder willkürlicher Größe sein. Bei gewissen Ausführungsformen kann sich die Chunk-Größe dynamisch ändern.
  • Zu Datendeduplizierungszwecken können Dateien durch Stubs ersetzt werden, die zu Datenblöcken zeigen, die innerhalb eines gemeinsamen Chunk-Speichers der nichtflüchtigen Ablage 140 abgelegt sind. Während des Dateizugriffs können die korrekten Blöcke/Chunks zusammengesetzt und dem Host-System 110 geliefert werden. Der Backup-Client (112/130) kann weiterhin eine oder mehrere Datenwartungsoperationen bezüglich der nichtflüchtigen Ablage 140 implementieren, wie etwa Optimierung, Müllsammlung, Wear Leveling und/oder Scrubbing.
  • Um die Deduplizierungsfunktionalität zu implementieren, kann das Backup-System 120 und/oder das Host-System 110 Metadaten führen, die Assoziationen zwischen Dateien und damit assoziierten Chunks führen, sowie Hash-Werte oder andere Kennungen, die mit den verschiedenen Dateien und/oder Chunks assoziiert sind, um die Identifikation von Modifikationen oder Änderungen in Benutzerdaten zu gestatten, die das Sichern oder Speichern solcher modifizierter oder geänderter Dateidaten gemäß dem relevanten Deduplizierungsprotokoll erforderlich machen.
  • Bei gewissen Ausführungsformen ist das System 100 konfiguriert zum Speichern jeder hashbaren Einheit einer Datei als eine separate Chunk-Datei. Solche Chunk-Dateien können mit dem mit den jeweiligen Chunks assoziierten hexadezimalen Hash-Wert benannt werden. Bei gewissen Ausführungsformen werden separate Chunk-Dateien mit einer “.hash”-Dateiendung gespeichert. Das Speichern von Chunks als separate Chunk-Dateien kann die Notwendigkeit zum Anhängen von Chunks an eine ständig wachsende Datei oder einen ständig wachsenden Blob verringern, wie oben beschrieben. Wo Backup-Repositories kein Verfahren zum Anhängen von Chunks an eine abgesetzte Datei bereitstellen, können deshalb hierin offenbarte Ausführungsformen das Speichern modifizierter/neuer Chunks durch das Host-System 110 im Backup-System 120 gestatten. Anstatt eine Anhäng-Funktion zum Anhängen des Chunks an die Datei aufzurufen, kann beispielsweise eine einfache Dateispeicherungsfunktion durch das Host-System 110 aufgerufen werden, um die separaten Chunk-Dateien in dem Backup-System 120 zu speichern.
  • Wenngleich nicht dargestellt, können das Backup-System 120 und das Host-System 110 verschiedene andere Komponenten und/oder Merkmale enthalten, wie etwa flüchtige und/oder nichtflüchtige Speichermodule, Datenübertragungskanäle/-schnittstellen, und/oder, und/oder Prozessoren, Zustandsmaschinen oder andere Rechenkomponenten.
  • Chunk-Level-Dateien
  • 2A ist ein Blockdiagramm, das eine Ausführungsform eines Daten-Blobs 201 von Benutzerdaten veranschaulicht, wobei der Blob 201 mehrere Dateien (Datei 1–Datei N) enthält. Der Ausdruck „Blob“ wird hier gemäß seiner breiten und gewöhnlichen Bedeutung verwendet und kann sich auf eine beliebige von mehreren Arten von Datenstrukturen oder Einheiten von Daten beziehen, die in einem Backup-Datenspeicher abgelegt werden können. Beispielsweise kann sich “Blob” auf ein binäres großes Objekt, eine derartige Datei, einen Strom, ein digitales Dokument, eine Tabelle, ein Verzeichnis, eine Datenbank, ein Archiv, ein Objekt oder irgendeine andere Art von Datenstruktur oder Sammlung von Daten in einer unstrukturierten, halbstrukturierten oder strukturierten Datenablageumgebung beziehen. Beispielsweise kann ein Blob eine beliebige Art von Daten enthalten, wie etwa Bilder, Audio oder andere Multimediaobjekte, einen binären ausführbaren Code oder eine andere Art von Daten. Der Blob 201 kann eine beliebige gewünschte oder praktische Größe wie etwa ungefähr 2GB, 4GB oder irgendeinen anderen Wert besitzen. Der Blob 201 kann eine beliebige Anzahl von Dateien von Daten wie etwa Benutzerdaten enthalten.
  • Bei gewissen Ausführungsformen kann eine Datei von Benutzerdaten mehrere Chunks von Benutzerdaten umfassen, wobei jeder Chunk einen einen Teilabschnitt der Benutzerdaten der Datei darstellt. 2B veranschaulicht ein Blockdiagramm, das eine Datei 203 mit mehreren Chunks (Chunk A–Chunk N) zeigt. Die Datei 203 kann weiterhin mit den Benutzerdaten der Datei assoziierte Metadaten 205 wie etwa einen Dateinamen 207 oder eine andere Dateikennung enthalten.
  • Wie oben beschrieben können bei gewissen Backup-Lösungen modifizierte/neue Chunks an eine ständig wachsende Datei angehängt werden, wobei Datei-Offset und Chunk-Längendaten in dem Backup-Datenspeicher zum Lokalisieren solcher Chunks geführt werden können. Da jedoch möglicherweise nicht alle Backup-Repositories dahingehend konfiguriert sind, das Anhängen von Chunks an Dateien auf eine derartige Weise zu unterstützen, kann es wünschenswert sein, dass individuelle Chunks in gewissen Situationen als separate Dateien gespeichert werden, wie hierin offenbart. Weiterhin können die separaten Chunk-Dateien mit dem Hash-Wert (z.B. hexadezimalen Wert) des jeweiligen Chunks benannt werden. Zu Veranschaulichungszwecken kann eine Chunk-Datei beispielsweise als “08EF8A59CC3B17D9.hash” oder ein anderer Hash-Wert und/oder einer Dateiendung benannt werden.
  • Die separaten, in individuellen Chunks von Daten abgelegten Dateien werden hierin als „Chunk-Dateien“ bezeichnet. Wie in 3A gezeigt, kann ein individueller Chunk 311 (Chunk A) als eine individuelle Chunk-Datei 302A gespeichert werden, wobei die Chunk-Datei die Chunk-Daten 311 sowie gewisse mit dem Chunk assoziierte Metadaten 305, wie etwa eine Chunk-Kennung 315, umfasst. Die Chunk-Kennung 315 kann beispielsweise ein mit der Chunk-Datei 302A assoziierter Dateiname oder dergleichen sein. Andere Chunks der Datei 203 können gleichermaßen als separate Chunk-Dateien gespeichert werden, wie etwa Chunk-Datei B 304, wie in 3A gezeigt. Analog zu der Chunk-Datei 302A enthält die Chunk-Datei 304 Metadaten 306 einschließlich einer Chunk-Kennung 316 sowie die Chunk-Daten 312. Die Nutzung von Chunk-Dateien, wie etwa die in 3B gezeigte, kann vorteilhafterweise dazu führen, dass die Menge an Daten reduziert wird, die gespeichert werden muss, was wiederum Ressourcen für andere Zwecke freimachen kann.
  • 3B veranschaulicht eine Chunk-Datei 302B, wobei die Chunk-Datei 302B einen Dateinamen 307 enthält. Bei gewissen Ausführungsformen kann der Dateiname 307 ein Hash-Wert der Chunk-Daten 311 sein oder ihm entsprechen. Beispielsweise wird bei gewissen Ausführungsformen ein Hash-Wert für jeden hashbaren Chunk einer Datei zu Zwecken des Identifizierens von Änderungen bei Daten für eine Deduplizierung berechnet. Wie in 3B gezeigt, kann ein derartiger Hash-Wert gleichzeitig als der Dateiname der Chunk-Datei 302B dienen, was eine effiziente Ablage von Metadaten gestatten kann, wobei nur ein einzelner Wert für den Hash-Wert und den Dateinamen der Chunk-Datei abgelegt wird.
  • Wie oben beschrieben wird eine Datendeduplizierung oftmals verwendet, um nur jene Abschnitte einer Datei zu sichern, die geändert worden sind oder neu sind, und um Chunks von Dateien über viele Dateien hinweg wiederzuverwenden. Um Änderungen und/oder neue Datei-Chunks zu bestimmen, kann ein Hash-Algorithmus über einen oder mehrere Abschnitte (z.B. Chunks) einer Datei ausgeführt werden, die sich geändert hat, um einen Hash-Wert für jeden Chunk zu generieren. Bei bestimmten Ausführungsformen erzeugt der Hash-Algorithmus einen eindeutigen Hash-Wert, um Kollisionen zu vermeiden, die ansonsten Probleme während des Wiederzusammensetzens von Daten verursachen könnten.
  • Der Backup-Client kann konfiguriert sein zum Vergleichen der neuberechneten Hash-Werte mit einer Liste von mit der Datei assoziierten gespeicherten Hash-Werten. Falls sich der Hash-Wert für einen Chunk oder Chunks der Datei geändert hat, werden in gewissen Ausführungsformen nur die geänderten Chunks als Chunk-Dateien gespeichert. Falls ein Hash-Wert als bereits in dem Backup-Ziel-Repository vorliegend erkannt wird, muss aufgrund der Eindeutigkeit der Hash-Werte der neue Chunk möglicherweise nicht gespeichert werden und kann als bereits gespeichert markiert werden.
  • Dateinamenverzeichnis-Ortsidentifikation
  • 4 ist ein Blockdiagramm, das eine Dateiverzeichnishierarchie gemäß einer oder mehreren hier offenbarten Ausführungsformen darstellt, wobei Chunk-Dateien in verschiedenen Ordnern der Hierarchie gespeichert werden können. Allgemein kann es wünschenswert sein, Situationen zu vermeiden, in denen zu viele Dateien in einem einzelnen Verzeichnisordner abgelegt werden, was unerwünschterweise einen übermäßigen Overhead einführen kann und/oder zu verlängerten Chunk-Dateiablage- und- Abrufzeiten führen kann. Um die Ablage von zu vielen Chunk-Dateien in einem einzelnen Verzeichnis zu vermeiden, können die Chunk-Dateien in einer Ordnerhierarchie gespeichert werden, wobei jeder Ordner nach einem Byte oder einem anderen Abschnitt oder einer anderen Partition des relevanten Hash-Wertformats (z.B. hexadezimaler Hash-Wert) benannt wird. Die dargestellte Hierarchie von 4 wird unten unter Bezugnahme auf ein beispielhaftes Hash-Format mit einem hexadezimalen Drei-Byte-Hash-Wert beschrieben. Wenngleich der hexadezimale Drei-Byte-Wert zu Beschreibungszwecken verwendet wird, versteht sich, dass Werte mit einem beliebigen Format oder einer beliebigen Länge in Abhängigkeit von der implementierten bestimmten Hash-Konvention implementiert werden können.
  • Bei gewissen Ausführungsformen ist der Pfad zu dem Ablageort einer Hash-Datei zur Erleichterung des Nachschlagens in den Dateinamen der Chunk-Datei codiert. Dadurch besteht möglicherweise keine Notwendigkeit zum Speichern eines separaten Pfadwegs in den Datenspeicher, der die Dateien, die gesichert worden sind, indexiert. Wie gezeigt können bestimmte Zeichen, Symbole oder Bits/Bytes des Dateinamens mit verschiedenen Ebenen der Dateisystemhierarchie assoziiert sein und können einen Dateiortspfad innerhalb der Hierarchie identifizieren. Da die mit den verschiedenen gespeicherten Chunk-Dateien assoziierten Hash-Werte von Natur aus eindeutige Werte sein können, nutzen gewisse Ausführungsformen deshalb den Vorteil einer derartigen Eindeutigkeit zu dem Zweck, die zum Lokalisieren der Chunk-Dateien in dem Dateiverzeichnis erforderliche Menge an Metadaten zu reduzieren.
  • 4 veranschaulicht ein Beispiel, das zeigt, wie ein derartiger, den Verzeichnispfad identifizierender Dateinamenmechanismus implementiert werden kann. Als ein Beispiel kann eine Datei, wie etwa eine Chunk-Datei 450, einen Dateinamen "08EF8B" besitzen. In der dargestellten Ausführungsform können jeweils zwei Symbole des hexadezimalen Werts eine separate Ebene in der Verzeichnishierarchie darstellen. Das heißt, die ersten beiden Symbole (oder zum Beispiel die letzten beiden Symbole) des Dateinamenwerts können einer höchsten Ebenen in der Verzeichnishierarchie entsprechen. Wenngleich in der dargestellten Ausführungsform zwei Symbole des Dateinamens jeder der jeweiligen Ebenen der Verzeichnishierarchie entsprechen, können andere Anzahlen von Symbolen oder Teilmengen des Dateinamenwerts/der Dateinamenkette zum Identifizieren der verschiedenen Ebenen der Verzeichnishierarchie verwendet werden.
  • Bezüglich des beispielhaften Dateinamens "08EF8B" kann deshalb "08" den Ordner 401 auf einer höchsten Ebene (Ebene 0) der relevanten Verzeichnishierarchie identifizieren. Deshalb kann die Datei 450 als in einem Unterordner oder einem untergeordneten Ordner des Elternordners 401 gespeichert identifiziert werden. Die übrigen Symbole des Dateinamens können jede der übrigen Ebenen der Hierarchie identifizieren. Beispielsweise können, wie gezeigt, das dritte und vierte Symbol "EF" den Ordner 411 der nächsten Ebene identifizieren, unter dem die Datei 450 abgelegt ist.
  • Die letzten beiden Zeichen "8B" identifizieren den untergeordneten Unterordner 422, in dem die Datei 450 abgelegt ist. Wie gezeigt, kann die Datei 450 eine Chunk-Datei mit dem Dateinamen sein, der die den Ablageort identifizierende Kette ist, die oben beschrieben ist, die den Ablageort der Chunk-Datei 450 identifiziert. Die Chunk-Datei 450 enthält weiterhin die Chunk-Daten.
  • Durch Implementieren des Ablageortspfads auf diese Weise können hierin offenbarte Ausführungsformen für reduzierte Metadatenanforderungen sorgen, da es möglicherweise nicht notwendig ist, den Dateioffset und die Anzahl von Bytes sowie Ablagepfadinformationen im Datenspeicher abzulegen. Verzeichnisbäumen wie der in 4 gezeigte können weiter für relativ schnellen und einfachen Zugang zu Chunk-Dateien sorgen.
  • Datei-Backup-/Wiederherstellungsprozesse
  • 5 veranschaulicht einen Prozess 500 zum Sichern einer Datei in einem Backup-System. Bei Block 502 beinhaltet der Prozess 500 das Bestimmen, dass sich eine in einem Backup-System gesicherte oder zu sichernde Datei geändert hat. Beispielsweise kann die Datei eine nicht zuvor im Backup-System abgelegte neue Datei sein, oder die Datei kann durch einen Host modifiziert worden sein, wobei solche Modifikationen in dem Backup-System erfasst werden sollen. Bei gewissen Ausführungsformen empfängt der Backup-Client eine Benachrichtigung über eine Änderung an der Datei.
  • Bei Block 504 beinhaltet der Prozess 500 das Berechnen von Hash-Werten von hashbaren Chunks der Datei. Ein derartiger Schritt kann das Identifizieren hashbarer Chunk-Abschnitte der Datei und das Berechnen von mit einem oder mehreren der hashbaren Chunks assoziierten Hash-Werte beinhalten. Bei gewissen Ausführungsformen beinhaltet der Prozess 500 das Berechnen von Hash-Werten nur für jene Chunks der Datei, die modifiziert worden sind oder neu sind.
  • Bei Block 506 beinhaltet der Prozess 500 das Vergleichen der berechneten Hash-Werte der Datei mit mit der Datei assoziierten gespeicherten Hash-Werten. Auf der Basis eines derartigen Vergleichs beinhaltet der Prozess 500 bei Block 508 das Bestimmen, welche der hashbaren Chunks der Datei sich geändert haben. Beispielsweise kann der Prozess 500 das Bestimmen beinhalten, ob ein neu generierter Hash-Wert bereits in dem relevanten Ablagemodul existiert; falls der generierte Hash-Wert nicht bereits in dem Ablagemodul existiert, kann ein derartiges Fehlen anzeigen, dass der assoziierte Chunk neu oder modifiziert ist und deshalb gesichert werden muss.
  • Bei Block 510 beinhaltet der Prozess 500 das Speichern der modifizierten oder neuen Chunks als separate Dateien in dem Backup-Datenspeicher. Die separaten Chunk-Dateien können gewisse Metadaten- oder Chunk-Kennungsdaten sowie die Chunk-Daten enthalten. Das heißt, anstatt neue/modifizierte Chunks an eine ständig wachsende Datei anzuhängen, kann der Chunk als eine unabhängige Datei gespeichert werden. Dies kann dem Backup-Client gestatten, standardmäßige Datei-E/A-Operationen über die verschiedenen Backup-Ziel-Repository-Medienarten zu verwenden, einschließlich Drittziele, die die Datei-Anhängoperationen nicht unterstützen.
  • Bei gewissen Ausführungsformen, wie bei Block 512 gezeigt, können die separaten Chunk-Dateien Dateinamen besitzen, die den Hash-Wert des jeweiligen gespeicherten Chunks enthalten. Beispielsweise kann die Chunk-Datei mit einer hexidezimalen Darstellung des Hash-Werts des Chunks benannt werden und kann eine ".-Hash"-Dateiendung besitzen. Wie oben ausführlicher beschrieben, können bei bestimmten Ausführungsformen die Hash-Wert-Dateinamen zum Identifizieren eines Ablageorts, wo die Chunk-Datei abgelegt wird, verwendet werden.
  • Bei Block 514 kann der Prozess 500 das Markieren des neuen oder modifizierten Chunks hinsichtlich des Backup-Datenspeichers beinhalten. Falls zusätzliche Chunks als Chunk-Dateien gespeichert werden müssen, beinhaltet der Prozess 500 das Zurückschleifen zum Block 510 von dem Entscheidungsblock 516.
  • 6 veranschaulicht einen Prozess 600 zum Wiederherstellen einer Datei von einem Backup-Speicher gemäß einer oder mehreren hierin offenbarten Ausführungsformen. Der Prozess 600 beinhaltet bei Block 602 das Empfangen einer Anforderung zum Wiederherstellen einer Datei, die in dem Backup-Datenspeicher gesichert worden ist. Die Anforderung kann eine bestimmte Version der wiederherzustellenden Datei anzeigen, wobei verschiedene Versionen der Datei entsprechend verschiedenen Zeitperioden beispielsweise verfolgt und/oder in dem Backup-System geführt werden. Beispielsweise kann ein relevanter Backup-Client eine Benachrichtigung empfangen, dass ein Benutzer gerne eine Version einer Datei wiederherstellen möchte, die gesichert worden ist.
  • Bei Block 604 beinhaltet der Prozess 600 das Abrufen einer Liste von mit der angeforderten Datei assoziierten Chunks. Beispielsweise kann die Liste in dem Backup-System wie etwa in dem Backup-Datenspeicher als ein Mechanismus zum Verfolgen der Orte von mit den bestimmten Dateien assoziierten Chunk-Dateien geführt werden. Die Chunks können hashbare Chunks der Datei sein, die die angeforderte Version der Datei bilden. Der Prozess kann das Konsultieren des Backup-Datenspeichers hinsichtlich der Datei zum Abrufen der Liste und/oder von identifizierten Chunks beinhalten.
  • Bei Block 606 beinhaltet der Prozess 600 das Erzeugen einer temporären Datei entsprechend der angeforderten wiederhergestellten Datei. Die temporäre Datei kann als die wiederhergestellte Datei aufgebaut werden, um zurück an den Host geliefert zu werden. Die Blöcke 608–612 veranschaulichen eine Schleife für das iterative Abrufen jeder der mit der angeforderten Datei assoziierten individuellen Chunk-Dateien. Das heißt, bei Block 608 werden eine mit den angeforderten Dateien oder einem Baum von dem Backup-Datenspeicher assoziierte Chunk-Datei und der Chunk der abgerufenen Chunk-Datei bei Block 610 an die temporäre Datei angehängt. Weil hashbare Chunks der Datei als Dateien anstelle von Offsets und Längen von einer größeren Datei gelesen werden, kann die in 6 dargestellte Backup-Lösung über verschiedene Backup-Plattformen kompatibel sein, da Support zum Lesen und Schreiben einer Datei möglicherweise breiter verfügbar ist als der Support für das Dateianhängen und/oder Lesen von willkürlichen Chunks einer Datei. Deshalb können hierin offenbarte Ausführungsformen gestatten, dass ein Backup-Client standargmäßige Datei-E/-A-Operationen über verschiedene Backup-Ziel-Repository-Medienarten verwendet.
  • Falls von der Datei zusätzliche Chunks übrig bleiben, die noch nicht abgerufen worden sind, erfolgt beim Entscheidungsblock 612 eine derartige Bestimmung, und falls die Chunks übrig bleiben, kehrt der Prozess 600 zurück zu Block 608 und gruppiert, bis alle der mit der angeforderten Datei assoziierten Chunks abgerufen und an die temporäre Datei angehängt worden sind. Die hashbaren Chunks der Datei können von dem Backup-Ziel-Repository unter Verwendung des Hash-Werts des Chunks abgerufen werden, um den hashbaren Chunk-Dateinamen zu bestimmen, wobei der Dateipfad durch den Dateinamen selbst identifiziert wird, wie oben beschrieben. Bei Block 614 beinhaltet der Prozess 600 das Liefern der wiederhergestellten Datei beispielsweise an ein Host-System. Die Datei kann an einem Ort und/oder einem Namen, die von den Benutzer geliefert werden, wiederhergestellt werden.
  • Hierin offenbarte Ausführungsformen können gegenüber gewissen existierenden Backup-Lösungen verschiedene Vorteile bereitstellen. Beispielsweise können die offenbarten Backup-Lösungen mit einer erheblichen Anzahl von Drittdaten-Repositories kompatibel sein, die durch hostseitige Backup-Clients verwendet werden können. Beispielsweise kann eine derartige verbesserte Effizienz besonders evident sein, wenn beispielsweise ein einzelnes Wort in einem relativ großen Dokument modifiziert wird, oder verstellt eine kleine Anzahl von Pixeln in einer relativ großen Bilddatei werden modifiziert. In einem derartigen Szenario wird gemäß gewissen, hierin offenbarten Ausführungsformen nur der Abschnitt der Datei, der sich geändert hat, und nicht die ganze Datei gespeichert, wodurch Zeit und/oder Ressourcen eingespart werden.
  • Zusätzliche Ausführungsformen
  • Der Fachmann versteht, dass bei einigen Ausführungsformen andere Arten von Daten-Backup-Systemen implementiert werden können, während man innerhalb des Schutzbereichs der vorliegenden Offenbarung bleibt. Außerdem können die in den hierin erörterten Prozessen unternommenen tatsächlichen Schritte von den beschriebenen oder in den Figuren gezeigten abweichen. Je nach der Ausführungsform können auch gewisse der oben beschriebenen Schritte entfernt werden und/oder andere können hinzugefügt werden.
  • Wenngleich gewisse Ausführungsformen beschrieben worden sind, sind diese Ausführungsformen lediglich als Beispiel vorgelegt worden und sollen den Schutzbereich nicht beschränken. Tatsächlich können die hierin beschriebenen neuartigen Verfahren und Systeme in einer Vielzahl anderer Formen verkörpert werden. Weiterhin können verschiedene Auslassungen, Substitutionen und Änderungen hinsichtlich der Form der hierin beschriebenen Verfahren und Systeme vorgenommen werden. Die beiliegenden Ansprüche und ihre Äquivalente sollen alle derartigen Formen oder Modifikationen abdecken, die in den Bereich und den Gedanken des Schutzes fallen würden. Beispielsweise können die in den Figuren dargestellten verschiedenen Komponenten als Software und/oder Firmware auf einem Prozessor, einer applikationsspezifischen integrierten Schaltung (ASIC), einem feldprogrammierbaren Gatearray (FPGA) oder dedizierter Hardware implementiert werden. Außerdem können die Merkmale und Attribute der oben offenbarten spezifischen Ausführungsformen auf unterschiedliche Weisen kombiniert werden, um zusätzliche Ausführungsformen auszubilden, die alle in den Schutzbereich der vorliegenden Offenbarung fallen. Wenngleich die vorliegende Offenbarung gewisse bevorzugte Ausführungsformen und Anwendungen liefert, liegen andere Ausführungsformen, die dem Durchschnittsfachmann offensichtlich sind, einschließlich Ausführungsformen, die nicht alle der hierin dargelegten Merkmale und Vorteile bereitstellen, ebenfalls innerhalb des Schutzbereichs der vorliegenden Offenbarung. Dementsprechend soll der Schutzbereich der vorliegenden Offenbarung nur durch Bezugnahme auf die beigefügten Ansprüche definiert werden.
  • Alle der oben beschriebenen Prozesse können in Softwarecodemodulen verkörpert und über diese vollständig automatisiert werden, die durch einen oder mehrere Allzweck- oder Spezialcomputer oder -prozessoren ausgeführt werden. Die Codemodule können auf einer beliebigen Art von computerlesbarem Medium oder einer anderen Computerablageeinrichtung oder Sammlung von Ablageeinrichtungen abgelegt werden. Einige oder alle der Verfahren können alternativ in spezialisierter Computerhardware verkörpert werden.

Claims (20)

  1. Rechensystem umfassend: eine Kommunikationsschnittstelle zum Kommunizieren mit einem nichtflüchtigen Speicher; und einen Controller, der konfiguriert ist zum: Bestimmen, dass eine in dem nichtflüchtigen Speicher abgelegte Datei modifiziert worden ist; Identifizieren eines Chunks der Datei, der modifiziert worden ist; Bestimmen eines mit dem modifizierten Chunk assoziierten neuen Chunks, wobei der neue Chunk die Modifikation widerspiegelt; Generieren einer separaten Chunk-Datei mit dem neuen Chunk und einem Dateinamen; und Speichern der Chunk-Datei in dem nichtflüchtigen Speicher unter Verwendung der Kommunikationsschnittstelle.
  2. Rechensystem nach Anspruch 1, wobei der Dateiname einen Ablageort innerhalb eines mit dem nichtflüchtigen Speicher assoziierten Datenverzeichnisses anzeigt, wobei das Ablegen der Chunk-Datei das Ablegen der Chunk-Datei an dem Ort umfasst.
  3. Rechensystem nach Anspruch 2, wobei durch den Controller separat von dem Dateinamen kein Pfadwert für den Ort abgelegt wird
  4. Rechensystem nach Anspruch 1, wobei der Controller eine Komponente einer über die Kommunikationsschnittstelle mit einer Datenablageeinrichtung mit dem nichtflüchtigen Speicher verbundenen Host-Einrichtung ist.
  5. Rechensystem nach Anspruch 1, wobei der nichtflüchtige Speicher und der Controller Komponenten eines Netzwerk-Laufwerks (NAS – Network-Attached Storage) oder eines Direct-Attached-Speicher-Laufwerks (DAS) sind.
  6. Rechensystem nach Anspruch 1, wobei der Controller weiterhin konfiguriert ist zum Generieren eines mit dem neuen Chunk assoziierten Hash-Werts.
  7. Rechensystem nach Anspruch 6, wobei der Hash-Wert ein hexadezimaler Hash-Wert ist.
  8. Rechensystem nach Anspruch 1, wobei die Chunk-Datei eine Hash-Datei ist.
  9. Rechensystem nach Anspruch 1, wobei der Controller weiterhin konfiguriert ist zum Rekonstruieren der Datei mindestens teilweise durch: Empfangen einer Anforderung zum Wiederherstellen einer Version der Datei; Identifizieren einer oder mehrerer mit der Version der Datei assoziierten Chunk-Dateien; Abrufen der einen oder mehreren identifizierten Chunk-Dateien; und Anhängen der abgerufenen einen oder mehreren Chunk-Dateien an eine wiederhergestellte Datei.
  10. Rechensystem nach Anspruch 9, wobei das Abrufen der einen oder mehreren identifizierten Chunk-Dateien das Bestimmen einer oder mehrerer Verzeichnisorte auf der Basis von Dateinamen der einen oder mehreren identifizierten Chunk-Dateien umfasst.
  11. Rechensystem nach Anspruch 9, wobei der Controller weiterhin konfiguriert ist zum Abrufen einer Dateien mit Chunks assoziierenden Tabelle.
  12. Rechensystem nach Anspruch 9, wobei der Controller weiterhin konfiguriert ist zum Liefern der wiederhergestellten Datei an eine Host-Einrichtung über ein Netzwerk, wobei das Rechensystem ein Backup-Server-System ist.
  13. Verfahren zum Sichern von Daten in einem Rechensystem, wobei das Verfahren Folgendes umfasst: Bestimmen, dass eine in einem nichtflüchtigen Speicher eines Rechensystems abgelegte Datei modifiziert worden ist; Identifizieren eines Chunks der Datei, der modifiziert worden ist; Bestimmen eines mit dem modifizierten Chunk assoziierten neuen Chunks, wobei der neue Chunk die Modifikation widerspiegelt; Generieren einer separaten Chunk-Datei mit dem neuen Chunk und einem Dateinamen; und Speichern der Chunk-Datei in dem nichtflüchtigen Speicher.
  14. Verfahren nach Anspruch 13, wobei der Dateiname einen Ablageort innerhalb eines mit dem nichtflüchtigen Speicher assoziierten Datenverzeichnisses anzeigt.
  15. Verfahren nach Anspruch 13, weiterhin umfassend das Generieren eines mit dem neuen Chunk assoziierten Hash-Werts
  16. Verfahren nach Anspruch 13, wobei die Chunk-Datei eine Hash-Datei ist.
  17. Verfahren zum Wiederherstellen von gesicherten Daten in einem Rechensystem, wobei das Verfahren Folgendes umfasst: Empfangen einer Anforderung zum Wiederherstellen einer Version einer in dem nichtflüchtigen Speicher eines Rechensystems abgelegten Datei; Identifizieren eines oder mehrerer, in dem nichtflüchtigen Speicher abgelegter, mit der Version der Datei assoziierter Chunk-Dateien, wobei jede der einen oder mehreren Chunk-Dateien einen Dateinamen besitzt; Abrufen der einen oder mehreren identifizierten Chunk-Dateien; und Anhängen der abgerufenen einen oder mehreren Chunk-Dateien an eine wiederhergestellte Datei.
  18. Verfahren nach Anspruch 17, wobei das Abrufen der einen oder mehreren identifizierten Chunk-Dateien das Bestimmen einer oder mehrerer Verzeichnissorte auf der Basis von Dateinamen der einen oder mehreren identifizierten Chunk-Dateien umfasst.
  19. Verfahren nach Anspruch 17, weiterhin umfassend das Abrufen einer Dateien mit Chunks assoziierenden Tabelle.
  20. Verfahren nach Anspruch 17, wobei der Dateiname jeder der einen oder mehreren Chunk-Dateien ein mit einer jeweiligen Chunk-Datei assoziierter Hash-Wert ist.
DE112016000176.2T 2015-03-30 2016-03-25 Datendeduplizierung unter Verwendung von Chunk-Dateien Pending DE112016000176T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US14/673,785 2015-03-30
US14/673,785 US9684569B2 (en) 2015-03-30 2015-03-30 Data deduplication using chunk files
PCT/US2016/024181 WO2016160555A1 (en) 2015-03-30 2016-03-25 Data deduplication using chunk files

Publications (1)

Publication Number Publication Date
DE112016000176T5 true DE112016000176T5 (de) 2017-08-31

Family

ID=57006349

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112016000176.2T Pending DE112016000176T5 (de) 2015-03-30 2016-03-25 Datendeduplizierung unter Verwendung von Chunk-Dateien

Country Status (4)

Country Link
US (1) US9684569B2 (de)
CN (1) CN107111460B (de)
DE (1) DE112016000176T5 (de)
WO (1) WO2016160555A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021101239B4 (de) 2020-01-27 2022-12-08 Hewlett Packard Enterprise Development Lp Schwellenwert des deduplizierungssystems basierend auf der abnutzung eines speichergeräts

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9367562B2 (en) * 2013-12-05 2016-06-14 Google Inc. Distributing data on distributed storage systems
US9659047B2 (en) * 2014-12-03 2017-05-23 Netapp, Inc. Data deduplication utilizing extent ID database
US9967093B2 (en) * 2015-03-25 2018-05-08 Intel Corporation Techniques for securing and controlling access to data
US10534671B1 (en) * 2016-06-28 2020-01-14 EMC IP Holding Company LLC Container image layer compaction
CN109391645B (zh) * 2017-08-03 2020-09-11 中国移动通信有限公司研究院 区块链轻量化处理方法、区块链节点及存储介质
CN110737635B (zh) * 2018-07-02 2023-02-10 深圳联友科技有限公司 一种数据分块方法
US11003629B2 (en) * 2018-10-31 2021-05-11 EMC IP Holding Company LLC Dual layer deduplication for application specific file types in an information processing system
AU2019438434B2 (en) * 2019-11-26 2021-10-21 Citrix Systems, Inc. Document storage and management
US11706203B2 (en) * 2021-05-14 2023-07-18 Citrix Systems, Inc. Method for secondary authentication

Family Cites Families (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7120692B2 (en) 1999-12-02 2006-10-10 Senvid, Inc. Access and control system for network-enabled devices
US8688797B2 (en) 1999-12-02 2014-04-01 Western Digital Technologies, Inc. Managed peer-to-peer applications, systems and methods for distributed data access and storage
US7934251B2 (en) 1999-12-02 2011-04-26 Western Digital Technologies, Inc. Managed peer-to-peer applications, systems and methods for distributed data access and storage
US9191443B2 (en) 1999-12-02 2015-11-17 Western Digital Technologies, Inc. Managed peer-to-peer applications, systems and methods for distributed data access and storage
US6499054B1 (en) 1999-12-02 2002-12-24 Senvid, Inc. Control and observation of physical devices, equipment and processes by multiple users over computer networks
US7587467B2 (en) 1999-12-02 2009-09-08 Western Digital Technologies, Inc. Managed peer-to-peer applications, systems and methods for distributed data access and storage
US8793374B2 (en) 1999-12-02 2014-07-29 Western Digital Technologies, Inc. Managed peer-to-peer applications, systems and methods for distributed data access and storage
EP1309901B1 (de) 1999-12-02 2008-05-21 Western Digital Technologies, Inc. System zum fernaufnehmen von fernsehprogrammen
US7917628B2 (en) 1999-12-02 2011-03-29 Western Digital Technologies, Inc. Managed peer-to-peer applications, systems and methods for distributed data access and storage
US7949564B1 (en) 2000-05-31 2011-05-24 Western Digital Technologies, Inc. System and method of receiving advertisement content from advertisers and distributing the advertising content to a network of personal computers
US7454443B2 (en) 2003-08-26 2008-11-18 Tamir Ram Method, system, and program for personal data management using content-based replication
EP1751745B1 (de) 2003-11-14 2019-07-10 Western Digital Technologies, Inc. Verwaltete peer-to-peer-anwendungen, systeme und verfahren für verteilten datenzugriff und verteilte datenspeicherung
US20080250085A1 (en) 2007-04-09 2008-10-09 Microsoft Corporation Backup system having preinstalled backup data
US20080270436A1 (en) * 2007-04-27 2008-10-30 Fineberg Samuel A Storing chunks within a file system
US8209540B2 (en) 2007-06-28 2012-06-26 Apple Inc. Incremental secure backup and restore of user settings and data
CN101370025A (zh) * 2007-08-17 2009-02-18 北京灵图软件技术有限公司 地理信息数据的存储方法、调度方法及管理系统
US8004791B2 (en) 2008-02-22 2011-08-23 Western Digital Technologies, Inc. Information storage device with a bridge controller and a plurality of electrically coupled conductive shields
US8452731B2 (en) * 2008-09-25 2013-05-28 Quest Software, Inc. Remote backup and restore
US20100211983A1 (en) 2009-02-19 2010-08-19 Pixel8 Networks, Inc. Virtual private content delivery network and method thereof
US9009429B2 (en) 2009-03-30 2015-04-14 Hewlett-Packard Development Company, L.P. Deduplication of data stored in a copy volume
JP4924645B2 (ja) 2009-03-31 2012-04-25 富士通株式会社 ストレージ制御装置、ストレージシステム及びコピー方法。
US8255661B2 (en) 2009-11-13 2012-08-28 Western Digital Technologies, Inc. Data storage system comprising a mapping bridge for aligning host block size with physical block size of a data storage device
US8285965B2 (en) 2009-11-20 2012-10-09 Western Digital Technologies, Inc. Aligning data storage device partition to boundary of physical data sector
US8526798B2 (en) 2009-12-23 2013-09-03 Western Digital Technologies, Inc. Portable content container displaying A/V files in response to a command received from a consumer device
US8458131B2 (en) 2010-02-26 2013-06-04 Microsoft Corporation Opportunistic asynchronous de-duplication in block level backups
US8370297B2 (en) * 2010-03-08 2013-02-05 International Business Machines Corporation Approach for optimizing restores of deduplicated data
CN101814045B (zh) * 2010-04-22 2011-09-14 华中科技大学 一种用于备份服务的数据组织方法
US8631284B2 (en) 2010-04-30 2014-01-14 Western Digital Technologies, Inc. Method for providing asynchronous event notification in systems
WO2011159322A1 (en) * 2010-06-18 2011-12-22 Hewlett-Packard Development Company, L.P. Data deduplication
US8762682B1 (en) 2010-07-02 2014-06-24 Western Digital Technologies, Inc. Data storage apparatus providing host full duplex operations using half duplex storage devices
GB2482128A (en) 2010-07-19 2012-01-25 Quantum Corp Delta chunks and delta hashes
US10019741B2 (en) 2010-08-09 2018-07-10 Western Digital Technologies, Inc. Methods and systems for a personal multimedia content archive
US8799231B2 (en) 2010-08-30 2014-08-05 Nasuni Corporation Versioned file system with fast restore
US8713265B1 (en) 2010-09-21 2014-04-29 Western Digital Technologies, Inc. Visual indicator of online backup
US9244779B2 (en) * 2010-09-30 2016-01-26 Commvault Systems, Inc. Data recovery operations, such as recovery from modified network data management protocol data
CN102184218B (zh) * 2011-05-05 2012-11-21 华中科技大学 一种基于因果关系的重复数据删除方法
US8612392B2 (en) 2011-05-09 2013-12-17 International Business Machines Corporation Identifying modified chunks in a data set for storage
US8904128B2 (en) 2011-06-08 2014-12-02 Hewlett-Packard Development Company, L.P. Processing a request to restore deduplicated data
US8990171B2 (en) * 2011-09-01 2015-03-24 Microsoft Corporation Optimization of a partially deduplicated file
CN103384256A (zh) * 2012-05-02 2013-11-06 天津书生投资有限公司 一种云存储方法及装置
US8780004B1 (en) 2012-01-31 2014-07-15 Western Digital Technologies, Inc. Dual configuration enclosure with optional shielding
US8819443B2 (en) 2012-02-14 2014-08-26 Western Digital Technologies, Inc. Methods and devices for authentication and data encryption
US8646054B1 (en) 2012-03-23 2014-02-04 Western Digital Technologies, Inc. Mechanism to manage access to user data area with bridged direct-attached storage devices
US8914634B2 (en) 2012-04-10 2014-12-16 Western Digital Technologies, Inc. Digital rights management system transfer of content and distribution
US8831217B2 (en) 2012-04-10 2014-09-09 Western Digital Technologies, Inc. Digital rights management system and methods for accessing content from an intelligent storage
CN103577278B (zh) 2012-07-30 2016-12-21 国际商业机器公司 用于数据备份的方法和系统
US9626373B2 (en) 2012-10-01 2017-04-18 Western Digital Technologies, Inc. Optimizing data block size for deduplication
US9262430B2 (en) * 2012-11-22 2016-02-16 Kaminario Technologies Ltd. Deduplication in a storage system
US9280482B2 (en) 2012-12-13 2016-03-08 Western Digital Technologies, Inc. Methods and systems for provisioning a bootable image on to an external drive
US20140169921A1 (en) 2012-12-19 2014-06-19 Mark Carey Cargo carrier
US20140344539A1 (en) 2013-05-20 2014-11-20 Kaminario Technologies Ltd. Managing data in a storage system
US9753944B2 (en) * 2013-12-27 2017-09-05 Cormentis Design Corporation System and method for streaming files through differential compression

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021101239B4 (de) 2020-01-27 2022-12-08 Hewlett Packard Enterprise Development Lp Schwellenwert des deduplizierungssystems basierend auf der abnutzung eines speichergeräts
US11609849B2 (en) 2020-01-27 2023-03-21 Hewlett Packard Enterprise Development Lp Deduplication system threshold based on a type of storage device

Also Published As

Publication number Publication date
WO2016160555A1 (en) 2016-10-06
US20160292048A1 (en) 2016-10-06
CN107111460B (zh) 2020-04-14
CN107111460A (zh) 2017-08-29
US9684569B2 (en) 2017-06-20

Similar Documents

Publication Publication Date Title
DE112016000176T5 (de) Datendeduplizierung unter Verwendung von Chunk-Dateien
DE102013204972B4 (de) Hybride Sicherung und Wiederherstellung eines sehr grossen Dateisystems unter Verwendung von Metadaten-Abbildsicherung und herkömmlicher Sicherung
US10108543B1 (en) Efficient physical garbage collection using a perfect hash vector
US10901861B2 (en) Systems and methods of restoring a dataset of a database for a point in time
US11182256B2 (en) Backup item metadata including range information
DE102008015662B4 (de) Beseitigung von Daten
US9852145B2 (en) Creation of synthetic backups within deduplication storage system by a backup application
DE112007003693B4 (de) Datenverarbeitungsvorrichtung und Verfahren zur Datenverarbeitung
US20190361850A1 (en) Information processing system and information processing apparatus
US20170123935A1 (en) Cloud object data layout (codl)
DE112013000900B4 (de) Bewahren von Redundanz in Datendeduplizierungssystemen unter Verwendung eines Anzeigers
DE112012004937T5 (de) Fingerabdruckbasierte Datendeduplizierung
DE112014003152T5 (de) Systeme und Verfahren für atomare Speicheroperationen
DE202010018481U1 (de) Asynchroner verteilter Objekt-Upload für replizierte Assoziativspeichercluster
DE112014000251T5 (de) Echtzeitklassifizierung von Daten in Datenkomprimierungsdomänen
US11243850B2 (en) Image recovery from volume image files
DE112017000167B4 (de) Verteilte Datendeduplizierung in einem Prozessorraster
DE112018000227B4 (de) Verfahren zum teilweisen Aktualisieren von Dateninhalten in einem verteilten Speichernetzwerk
US10331362B1 (en) Adaptive replication for segmentation anchoring type
US20210081431A1 (en) Any point in time replication to the cloud
US11593304B2 (en) Browsability of backup files using data storage partitioning
US20200409570A1 (en) Snapshots for any point in time replication
DE112016004457T5 (de) Vervielfältigen von Daten in Datenspeichervorrichtungen eines Verknüpfungsvolumens
US9626332B1 (en) Restore aware cache in edge device
DE102021126985A1 (de) Speicherung einer kleinen objektdarstellung in einem deduplizierungssystem

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R082 Change of representative

Representative=s name: DEHNSGERMANY PARTNERSCHAFT VON PATENTANWAELTEN, DE

Representative=s name: DEHNS GERMANY PARTNERSCHAFT MBB, DE