Fortschrittsanzeige Backup bleibt bei Null stehen

Mac OS Server 10.11.6
4D Server v16 R2

Das Backup läuft komplett durch, aber die Fortschrittsanzeige bleibt bei Null stehen.
Die Datenbank selbst hat nur einige 100 MB, allerdings werden etwa 46 GB Fotos als externe Daten gespeichert.

Backup wurde für 4D Datenbanken entwickelt - und kann auch nebenbei einige externe Dateien mitsichern.

Ihr Anwendungsfall ist das Gegenteil, kaum 4D Datenbank, sehr viel externe Dateien. Dafür ist es nicht optimiert. Die Fortschrittsanzeige zeigt den Stand der .4DD/Index Sicherung an, die externen Dateien werden nicht berücksichtigt.
Das wäre jetzt eine machbare Kleinigkeit - aber - die Sicherung ist nicht optimal.
Jeden Tag werden alle 46 GB gesichert, ohne irgendeine Optimierung. Das ist überhaupt nicht effizient.

Fotos ändern sich nicht täglich, vermutlich kommen nur neue dazu, die alten werden nie oder kaum geändert. Warum jeden Tag alle Bilder neu sichern?

Das war doch eigentlich die Idee auch am Auslagern, damit sie nicht die tägliche Wartung verlangsamen…

Nehmen Sie den Ordner aus dem 4D Backup raus - und lassen Sie parallel ein System oder 3rd Party Backup laufen. Das sichert nur geänderte Dateien und ist dadurch drastisch schneller.
Unter OS X bietet sich hier TimeMachine oder Rsync an.

Hallo Herr Maul,

danke für Ihre Antwort. Ich habe mich leider nicht korrekt ausgedrückt: Die Fotos sind Teil der 4D-Struktur, nur werden sie außerhalb der Datendatei (Einstellung in der Struktur) gespeichert. Da sollten doch die Optimierungsprozesse des Backupvorgangs greifen?

nein, es sind externe Files (im Finder als einzelne Dateien sichtbar).

Der einzige Grund Dateien außerhalb der Datendatei zu speichern ist diese nicht im Backup zu haben (und nicht bei MSC zu komprimieren/reparieren) - sondern extern zu verwalten.

Wenn Sie diese per 4D Backup sowieso sichern wollen, können Sie sie auch in der Datendatei sichern. Sie werden merken, Backup/Restore wird dann schneller, auch das Kopieren im Finder des Ordners wird schneller.

Allerdings ist bei 40 GB Bilder und < 1 GB Daten grundsätzlich besser die Bilder extern zu halten - und per TimeMachine/Rsync nur die täglichen Änderungen zu synchronisieren.

Hallo Herr Maul,

was spräche dagegen die Bilder in die Datenbank zu holen? - Mal abgesehen vom “dicken” 4D Datenfile.

Nur “Mal abgesehen vom “dicken” 4D Datenfile.”

Mich persönlich würde es stören, täglich 40 GB zu sichern wenn sich nur 5 MB geändert haben.
Ich kenne jetzt die Quelle/Wertigkeit der Fotos nicht, mir persönlich sind meine Bilder wichtig. Die sind auf 3 Platten + 1xCloud-Speicher. 1 Platte der Rechner selbst, 1 im NAS im Keller, 1 extern weit entfernt gelagert (vermutlich wegen Cloud überflüssig, alte Gewohnheit).
Änderungen gehen täglich auf NAS und Cloud, ab und an auf die externe Platte.
Ich kann (und will) nicht täglich 40 GB hochladen. Nur neue oder geänderte Bilder sind aber kein Problem. Und RSync macht das zuverlässig auf andere Platten/NAS/Cloud.

Aus meiner Sicht ist es daher “das dicke file”.

Sehe ich ansich genau so. Beim Kunden ist es eher ein Zugriffsproblem. Client-Server, kein Thema, aber das sollen Einzelplatzsysteme sein und nicht jeder darf an die Bilder.

Bislang lagen die in …/Application Support/4D/Bilder/…, nicht gerade sicher, mal abgesehen vom Aufwand bei neuen Rechnern.

Da muss ich jetzt auch nachfragen: 4D Backup sichert doch den .ExternalData Ordner automatisch mit - kann man das abstellen? Oder gibt es einen Unterschied zwischen “Automatischem” und “Manuellem” Modus?

4D Backup sichert doch den .ExternalData Ordner automatisch mit - kann man das abstellen?

eigentlich nicht - wenn müssen Sie das gezielt aktivieren.

Backup Preferences - dort werden die zusätzlich gesicherten Dateien/Ordner angezeigt.

Das sollte in jedem Fall die Indx Datei sein. Weitere Ordner/Dateien nach Bedarf.

Hmm, gerade nochmal getestet: neue Datenbank angelegt, eine Tabelle mit 2 Feldern, eines davon ein Bildfeld mit Einstellung “Außerhalb der Datendatei”. Backup Einstellungen bis auf das Ziel nicht geändert:

[]19677557;“Backupeinstellungen”[/]

Backup durchgeführt, Datenbank beendet, Wiederherstellen: der .ExternalData-Ordner wird mit wiederhergestellt. Auch die Größe der .4BK Datei weist darauf hin, dass die Bilder mit drin sind.

Sicherheitshalber auch ohne Logbuch getestet: gleiches Ergebnis.

Die Lösung ist also “Datendatei” nicht ankreuzen, stattdessen die .4DD manuell hinzufügen?

sorry, mein Fehler, nicht ausreichend weit ausgeholt.

große “Feldtypen” (Blobs, Bilder, Text, Objekte) können in 4 Varianten gespeichert werden:

Bei Varianten 1-3 werden Änderungen mit im Journal gespeichert (das vollständige Objekt). Deshalb werden die Daten auch automatisch ins Backup aufgenommen (sonst wären die Daten im Journal sinnlos).
Das erlaubt somit eine sekundengenaue Rekonstruktion.

Variante 4 nimmt weder ins Journal auf, noch ins Backup. Deshalb weichen die Testergebnisse davon ab - eben abhängig wie verwaltet.

Siehe auch: http://www.youtube.com/watch?v=vVej7SwI-uM&t=40m10s

Trotz aller Diskussionen:

Der Fortschrittsbalken bewegt sich bis zum Ende des Backups keinen Millimeter. Das sollte doch ein Bug sein?

ich habe das mit Bildern in einem externen Ordner gespeichert getestet. Allerdings mit der bereits verfügbaren v16 R3, auch wenn wir mit R2 keinen bekannten Bug dazu hatten.

Ich hatte bei 4D, 4D Server 32 bit und 4D Server 64 bit einen Ablaufbalken. In allen Modi, interpretiert, kompiliert und enginiert.

Ich kann hier keinen Bug nachvollziehen.