> For the complete documentation index, see [llms.txt](https://docs.flosum.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flosum.com/backup-and-archive/backup-and-archive-docs-de/backup-and-archiv/backups/binary-daten-backup-limits-verstehen.md). # Binary-Daten-Backup-Limits verstehen ## Überblick Dieser Artikel erklärt die **Grenze für die Sicherung binärer Daten** Funktion, die während der ersten vollständigen zusammengesetzten Sicherung einer neu verbundenen Organisation angewendet wird. Die Funktion begrenzt die Anzahl der binären Datensätze (ContentVersions, Attachments usw.), die pro Ausführung während der anfänglichen Sicherungsphase verarbeitet werden. Standardmäßig werden bis zu **5,000** binäre Datensätze pro Ausführung gesichert. Die Sicherung läuft automatisch über mehrere Ausführungen hinweg weiter, bis jeder binäre Datensatz mindestens einmal gesichert wurde. Danach wird die Begrenzung aufgehoben, und Sicherungen laufen normal und verarbeiten nur neue und geänderte Datensätze. {% hint style="info" %} #### Salesforce-Einschränkung Salesforce behandelt API-Aufrufe für binäre Datensätze anders als Standarddatensätze, was für große Organisationen eine reale Einschränkung darstellt: * **Salesforce-API-Einschränkung:** Binäre Daten (ContentVersion, Attachments) werden Datensatz für Datensatz und nicht gesammelt vorbereitet und bereitgestellt. In Organisationen mit großen Mengen binärer Daten kann dies dazu führen, dass Sicherungsaufträge stundenlang laufen oder nicht mehr reagieren. * **Es gibt keine Umgehungslösung:** Dies ist eine Einschränkung der Salesforce-Plattform, und Salesforce bietet keine API-Konfiguration oder Infrastrukturänderungen an, um sie zu beheben. * **Branchenstandard:** Alle großen Backup-Anbieter setzen eine ähnliche Grenze. OwnBackup beispielsweise verwendet standardmäßig 2.000 Datensätze pro Ausführung. Unser Standardwert ist 5.000 und bietet damit für die meisten Organisationen eine schnellere Abdeckung. * **Bessere Erfahrung beim ersten Lauf:** Ohne Begrenzung kann eine anfängliche Sicherung in einer großen Organisation so lange dauern, dass das Produkt defekt erscheint. Mit der Begrenzung wird die erste Sicherung schnell abgeschlossen und läuft inkrementell weiter, sodass Kunden die App sofort nutzen können. {% endhint %} ## Funktionsweise Die Begrenzung ist in den Organisationseinstellungen konfigurierbar und gilt nur für die erste vollständige Composite-Sicherung einer Organisation. Sie gilt nicht für Template Backup, Template Archive oder Import Backups/Archives. * **Standardwert (Mindestwert):** 5.000 Datensätze pro Ausführung * **Maximalwert:** 999.999 Datensätze pro Ausführung Alle Nicht-Binärdaten-Datensätze (Standardobjekte, benutzerdefinierte Objekte, Metadaten) werden bei jeder Ausführung immer vollständig gesichert. Die Begrenzung gilt nur für binäre Datensätze während der anfänglichen Sicherungsphase. Sobald die Anzahl pro Ausführung erreicht ist, wird der Auftrag ordnungsgemäß abgeschlossen, und der nächste geplante Lauf setzt dort fort, wo er aufgehört hat. Dieser Prozess läuft automatisch weiter, bis alle binären Datensätze mindestens einmal gesichert wurden. Danach gilt die Begrenzung nicht mehr, und zusammengesetzte Sicherungen laufen normal. ## Die richtige Grenze wählen Die richtige Grenze für die Sicherung binärer Daten hängt von der Größe und Art der Dateien in Ihrer Organisation ab. Verwenden Sie die folgenden Richtlinien, wenn Sie die Grenze ändern. * **Viele kleine Datensätze**: Verwenden Sie eine höhere Grenze für die Sicherung binärer Daten, um die anfängliche Sicherung zu beschleunigen und die Anzahl der benötigten Ausführungen zu reduzieren. * **Große Dateien (hunderte MB oder 1–2 GB pro Datensatz)**: Verwenden Sie den Standardwert (5.000), um langlaufende Vorgänge und mögliche Zeitüberschreitungen zu vermeiden. ### Beispiel In diesem Beispiel hat eine Organisation mit 80.000 binären Datensätzen eine Grenze für die Sicherung binärer Daten von 20.000 Datensätzen festgelegt. Die folgende Tabelle zeigt, was bei jeder vollständigen zusammengesetzten Sicherungsausführung passiert. | **Ausführung** | **Nicht-binäre Datensätze** | **Gesicherte binäre Datensätze** | | ---------------------------- | ----------------------------- | -------------------------------- | | Ausführung 1 (Vollsicherung) | Vollständig gesichert | Datensätze 1 – 20.000 | | Ausführung 2 (Composite) | Neue und geänderte Datensätze | Datensätze 20.001 – 40.000 | | Ausführung 3 (Composite) | Neue und geänderte Datensätze | Datensätze 40.001 – 60.000 | | Ausführung 4 (Composite) | Neue und geänderte Datensätze | Datensätze 60.001 – 80.000 | | Ausführung 5+ (Composite) | Neue und geänderte Datensätze | *Keine Begrenzung — Normalmodus* | Die Begrenzung gilt über die Ausführungen 1–4 hinweg, bis alle 80.000 Dateidatensätze mindestens einmal gesichert wurden. Ab Ausführung 5 wird die Begrenzung aufgehoben, und der Auftrag läuft im Normalmodus. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.flosum.com/backup-and-archive/backup-and-archive-docs-de/backup-and-archiv/backups/binary-daten-backup-limits-verstehen.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.