parstore

S3-kompatibelverschlüsseltverteilt

Speicher, der keinem Hoster allein gehört.

parstore verschlüsselt jede Datei, zerlegt sie in Fragmente und verteilt diese auf unabhängige Hoster, Rechenzentren und Länder. Fällt ein Hoster aus, wird gesperrt oder geht pleite, bleiben die Daten lesbar. Wer einen einzelnen Speicher stiehlt, findet nur verschlüsselte Bruchstücke.

So funktioniert es Funktionen ansehen
  • 4+2zwei Hoster dürfen gleichzeitig ausfallen
  • 1,5×Speicherbedarf statt 3× mit Kopien
  • AES-256GCM, eigener Schlüssel je Chunk
Eine Datei wird in sechs Fragmente zerlegt Eine verschlüsselte Datei wird in vier Daten- und zwei Paritätsfragmente zerlegt. Jedes Fragment liegt bei einem anderen Hoster in einem anderen Land. Ein Hoster ist ausgefallen, die Datei bleibt aus den übrigen vier Fragmenten lesbar. Datei verschlüsselt D1 D2 D3 D4 P1 P2 DEHoster A ATHoster B NLHoster C FRHoster D PLHoster E FIHoster F Lesbar: 5 von 6 erreichbar, 4 genügen

Prinzip

Mathematik statt Kopien.

Eine vollständige Kopie bei einem zweiten Anbieter verdoppelt die Kosten und schützt nur gegen genau einen Ausfall. parstore nutzt Reed-Solomon-Codes: Aus beliebigen k von k+m Fragmenten lässt sich jede Datei wiederherstellen. Mit 4+2 übersteht sie zwei gleichzeitige Hoster-Ausfälle bei 1,5-fachem Speicher.

  1. Verschlüsseln

    Jeder Chunk wird mit einem eigenen Schlüssel (AES-256-GCM) verschlüsselt, bevor er das Gateway verlässt. Kein Hoster sieht Klartext oder Schlüssel.

  2. Zerlegen

    Der verschlüsselte Inhalt wird in k Datenfragmente geteilt, dazu kommen m Paritätsfragmente.

  3. Verteilen

    Jedes Fragment landet bei einem anderen Hoster, Rechenzentrum oder Land. Bestätigt wird ein Schreibvorgang erst, wenn das Schutzziel erreicht ist.

  4. Wiederherstellen

    Beim Lesen genügen beliebige k Fragmente. Fehlt eines, wird es im Hintergrund neu berechnet und anderswo abgelegt.

vertrag-2026.pdfVerschlüsselt · Codierung 4+2 · Speicherbedarf 1,5×
  • Datenfragment
  • Paritätsfragment
  • D1
    Hoster ADeutschland
    erreichbar
  • D2
    Hoster BÖsterreich
    erreichbar
  • D3
    Hoster CNiederlande
    ausgefallen
  • D4
    Hoster DFrankreich
    ausgefallen
  • P1
    Hoster EPolen
    erreichbar
  • P2
    eigene VMFinnland
    erreichbar

Datei weiterhin lesbar. 4 von 6 Fragmenten erreichbar, 4 werden gebraucht. Im Hintergrund berechnet parstore die fehlenden Fragmente neu und legt sie bei anderen Hostern ab.

Funktionen

Ein Speicher, der sich selbst pflegt.

Nach außen ein normaler S3-Speicher. Nach innen ein System, das Ausfälle selbst behebt und Kosten, Geschwindigkeit und Ausfallsicherheit abwägt, mit Sicherheit immer an erster Stelle.

S3-kompatibel

SigV4, Multipart, Range-Reads, bedingte Anfragen und die Prüfsummen aktueller SDKs. Getestet mit dem AWS SDK und der aws-cli. Clients verbinden sich über einen Loadbalancer mit Failover.

Selbstheilung

Fehlende oder beschädigte Fragmente werden aus den übrigen neu berechnet. Ein Scrubber prüft laufend die Prüfsummen, ohne dafür Schlüssel zu brauchen.

Snapshots und Deduplizierung

Bucket-Snapshots nach Zeitplan mit Aufbewahrungsregeln; Dateien, Ordner oder ganze Buckets zurückholen. Gleiche Inhalte innerhalb eines Kunden werden nur einmal gespeichert.

Dateibereich im Browser

Ordner, Uploads, Vorschau, Suche, Versionen und Papierkorb. Freigabelinks mit Passwort und Ablaufdatum, Dateianfragen für Externe, private Bereiche und Aufbewahrungsregeln.

Desktop-Client mit Laufwerken

Buckets als Laufwerk oder Ordner unter Windows, macOS und Linux. Anmeldung über den Browser, eigene Zugangsschlüssel je Gerät, automatische Updates.

Backups zu und von Kundenservern

Kopien von Buckets auf SFTP-, FTP(S)- oder S3-Server mit datiertem Versionsordner, und Sicherungen solcher Server nach parstore. Bei Anzeichen eines Angriffs hält der Lauf an und wartet auf Freigabe.

Datenresidenz

Hoster, Land und Standort werden als getrennte Ausfallbereiche bewertet. Je Kunde lässt sich festlegen, in welchen Ländern Fragmente liegen dürfen, etwa nur in der EU.

Kostenoptimierung

Einkaufspreise je Backend, Lesen über günstige Fragmente zuerst und eine Simulation, welche Backends sich leeren lassen, mit monatlicher Ersparnis und einmaligen Umzugskosten.

Klein anfangen, ohne Umbau wachsen

Start auf einem Server. Weitere Server werden aufgenommen und führen die Metadaten über Raft mit; jeder Server ist Gateway. Updates laufen gestaffelt, Umcodieren im Hintergrund.

Wiederherstellung aus den Backends

Die Metadaten werden regelmäßig verschlüsselt und codiert über mehrere Backends gesichert. Mit dem Wiederherstellungs-Kit entsteht daraus eine neue Instanz.

Mandanten und Abrechnung

Kunden mit eigenem Portal, Team, Quotas und Zugangsschlüsseln. Speicher, Traffic und Anfragen werden stündlich je Kunde und Bucket erfasst; Einkaufs- und Verkaufspreise mit Margen-Warnungen.

API zuerst

Alles, was die Oberfläche kann, geht auch über eine selbstdokumentierende API mit Beispielen. Gefährliche Aktionen haben Probelauf, Bestätigung und Audit-Eintrag.

Sicherheit

Ein gestohlener Speicher ist wertlos.

Verschlüsselt wird vor dem Zerlegen. Ein einzelner Hoster hält nur verschlüsselte Bruchstücke ohne Namen und Zuordnung, und nie mehr davon, als verloren gehen dürfen.

  • Schlüssel je Chunk

    AES-256-GCM mit eigenem Schlüssel für jeden Chunk. Bucket- und Mandantenschlüssel bleiben im Management, nie bei einem Hoster.

  • Prüfbar ohne Schlüssel

    Jedes Fragment trägt Prüfsumme und MAC. Defekte werden beim Scrubben erkannt und repariert, ohne dass Klartext entsteht.

  • Kein Ack ohne Schutzziel

    Ein Schreibvorgang wird erst bestätigt, wenn er nach der Regel seiner Speicherklasse sicher verteilt ist. Tests prüfen das bei jedem Build.

  • Zwei Faktoren, immer

    Pflicht-2FA mit TOTP, Rollen, Sitzungsverwaltung, Argon2id für Passwörter und ein Audit-Log für jede Änderung.

  • Schlüssel-Export

    Root- und Wiederherstellungsschlüssel lassen sich mit Passphrase und frischem zweiten Faktor exportieren und vorab auf Lesbarkeit prüfen.

  • Löschen mit Netz

    Destruktive Aktionen haben Probelauf und Wartefrist: Papierkorb für Dateien, Wiederherstellungsfrist für Buckets und Kunden.

Für wen

Für alle, die nicht von einem Anbieter abhängen wollen.

Passt gut

  • Eigenbetrieb mit gemischter Infrastruktur aus VMs, Managed-S3 und eigenen Servern
  • Kleine und mittlere Unternehmen, die Ausfälle einzelner Hoster überstehen wollen
  • Backups, Archive und Medienbestände bis zu sehr großen Dateien
  • Teams, die einen Dateibereich mit Freigabelinks für Mitarbeiter und Externe brauchen
  • Anbieter, die Speicher an eigene Kunden weitergeben wollen
  • Wer klein auf einem Server beginnen und später verteilen will

Passt weniger gut

  • Datenbanken mit sehr vielen kleinen, latenzkritischen Schreibvorgängen
  • Anforderungen, die heute schon ISO 27001, BSI C5 oder ein vertragliches SLA verlangen
  • Wer einfach den billigsten einzelnen Bucket sucht
  • Wer auf einem Einzelserver die Ausfallsicherheit eines verteilten Systems erwartet

parstore ist ein junges Produkt in der Laborphase. Weitere Zugänge wie SFTP, WebDAV, NFS und SMB sind geplant.