Backup auf externer Festplatte

Meinst du, dass du mehr/bessere Antworten bekommst, wenn du den Text größer schreibst, oder hast du einfach nur Probleme mit den Augen?

Falls nicht, stelle doch einfache Fragen, die man auch einfach beantworten kann!

Zitat von abrisssbirne

Das Backup ist 354GB (Aber eigentlich ist das Speichervolumen auf der Qnap 388GB)

Warum ist es kleiner?

Vergleichst du hier Äpfel mit Birnen?

Welche Größe gibst du an, physisch oder logisch? Ist die Blockgröße bei beiden Platten ident? Hast du beim Sicherungsjob einen Filter eingestellt, dass bestimmte Files nicht kopiert werden (Temp-Files, Systemfiles, leere Files, ...)?

Zitat von abrisssbirne

Und ZB. bei Fotos ist das Datum weg wann die Aufnahme gemacht wurde ????( das wäre Sch......)

Ganz einfach, Pustekuchen L

Wie geschrieben, hängt es sowohl vom gewählten Backupverfahren als auch dem Dateisystem des Speicherzieles ab, was alles mit in das Backup eingeht. Das interne Dateisystem ext4 bei QTS und das Dateisystem NTFS Deines externen Speichers sind nahe genug, um wenigstens die Standarddateiattribute mitzusichern. Dazu gehört für mich auch das Datum einer Datei (z.B. eines Fotos). Und viele Fotoformate haben in ihrer Datenstruktur auch noch Felder für Aufnahmedatum u.a.m. Das sind somit Dateiinhalte, keine Dateiattribute. Solche Inhalte fliessen sowieso in das Backup ein. Von daher ist Deine Sorge an dieser Stelle unbegründet.

Um am Beispiel von Fotos einer Fotosammlung zu bleiben, so gibt es Fotosammlungen, die nicht physikalisch sind, sondern allein an Hand von Attributen verwaltet werden. Bei derartig logischen Fotosammlungen wäre dann nicht sichergestellt, dass diese logischen Abgrenzungen erhalteb blieben. Wenn solche Fotosammlungen aber z.B. in verschiedenen Ordnern abgelegt sind, dann bleibt eine solche Trennung und Strukturierung für das Backup üblicherweise erhalten. Ähnlich ist es mit Verschlagwortung von Fotos. Werden solche Schlagworte innerhalb der Datenstrukturen der Fotos hinterlegt, fliessen sie als Inhalt in das Backup ein. Sind solche Schlagworte aber außerhalb der Fotos verwaltet und gespeichert, so ist nicht automatisch sichergestellt, dass eine solche Zuordnung im Rahmen eines Backups erhalten bleibt. Gerade bei größeren Fotosammlungen bedeutet eine solche Verschlagwortung erhebliche Arbeit und Wert. Auch dafür gibt es prinzipiell Lösungen, die im Bedarfsfall näher geprüft werden sollten. Wenn dagegen die Schlagworte innerhalb der Fotos gespeichert werden, stellt sich dieses Problem nicht. Wenn man Fotos allerdings vermarktet, dass will man bestimmte Schlagworte in den Fotos abgelegt haben, und andere Schlagworte sicher nicht mit Kunden teilen.

Moin,

Vielen Dank für die Unterstützung!

Ich wusste nicht dass nur eine Schriftgröße erlaubt ist!

Ja ich kann schlecht kucken!

Mein Qmanager auf meinem Handy zeigt beim Speicher:

Belegt:388.37 GB

Und das Backup war Kleiner!

Meine Sorge war ob nicht alles drauf ist!

Ob das jetzt physisch oder logisch ist weiß ich nicht!

Zu 99% sind es Fotos (davon ca.10% kleine Filme) die von meinen iPhone über Qfile per Whlan übertragen werden, wird den da das Aufnahme Datum mit Übertragen?

Es sind schon unterschiedliche Schriftgrößen erlaubt, wüsste jetzt nicht warum man die nicht auch "hie und da" ändern dürfte.

Den kompletten Text groß schreiben kommt erst mal etwas "aufdringlich" rüber, bei Augenproblemen spaße ich aber auch nicht mehr und lasse meine Kommentare dazu lieber sein ...

Zu deiner Frage, da kann man aus der Ferne nicht so viel dazu feststellen. QFile habe ich nicht in Verwendung. Bei normalem Backup via RTRR-Job habe ich per Default einen Filter aktiviert, der Systemfiles und temp Files vom Kopieren ausnimmt. Dadurch stimmt die Anzahl an Files schon mal nicht überein.

Die Fotos, die ich von der Kamera, bzw. Handy, über den PC auf die NAS kopiere, behalten das Aufnahmedatum an und für sich bei. Bei der Digitalkamera sind die EXIF-Daten auf jedem Fall richtig. Beim Erstellungsdatum ist das so eine Sache, drehe ich die Bilder am PC, wird sofort das Erstellungsdatum verändert, da muss ich selber höllisch aufpassen.

Einzige Abhilfe, die ich für mich dazu gefunden habe, die Fotos gleich von Beginn an mit dem Aufnahmedatum umzubenennen, dann bleibt das "für immer" nachvollziehbar und ich kann die Fotos chronologisch ablegen (auch nach mehrmaligem Bearbeiten ...)

Der physisch verwendete Platz wird bei unterschiedlichen Speichermedien (Festplatten unterschiedlicher Blockgröße) auch nie gleich sein. Vergleichbar mit Schuhen im Schuhkarton. Hast du gleich große Schuhe, aber unterschiedlich große Kartons, wirst du für die gleiche Anzahl an Schuhen, mehr Platz mit den großen Kartons brauchen ...

Als Faustregel kannst du davon ausgehen, dass je größer die Festplatte ist, die Blockgröße größer wird (die kleinste ansprechbare Speicherstelle auf der Disk). D.h. eine gleich große Datei wird auf einer großen Disk mehr Platz belegen, als auf einer kleinen SD-Karte.

So auf die Schnelle kannst du das mit einfachen Mitteln erst mal über die Anzahl an Files prüfen. Die solltest du am Handy, je Ordner sehen können, und auf der NAS auch im Filemanager sehen. Dann kannst du noch immer manuell nachprüfen, was warum nicht dabei ist ...

Zitat von abrisssbirne

wird den da das Aufnahme Datum mit Übertragen?

Davon gehe ich aus, sowohl bei den Dateiattributen als auch den Dateiinhalten (EXIF-Struktur). Wenn ich in der Warnung von Dateiattributen lese, dann vermute ich bei hinreichend ähnlichen Dateisystemen insbesondere Spezialrechte, evtl. auch ACL.

Das Beispiel mit logischen Alben sollte kein Problem darstellen, solange eine Restaurierung wieder auf die ursprüngliche Quelle geht. Bei logischen Alben ist es eine Frage, wo diese Zuordnung (zu Alben) abgespeichert wird, ob diese bei Restaurierung auf ein anderes Gerät erhalten bzw. verfügbar bleibt. Wenn diese in der selben Datei z.B. in Feldern der EXIF-Struktur erfolgt, sollte diese Zuordnung auch geräteübergreifend erhalten bleiben.

Und der Hinweis von RedDiabolo ist davon unabhängig, dass jegliche Bildbearbeitungssoftware diese Daten prinzipiell verändern kann, solange das Speichermedium schreibbar eingebunden ist, und damit bestehende Werte überschreiben kann. Linux bietet dafür Vorgehensweisen an. Aber wenigstens ein dafür benötigtes Dateisystem ist bei QTS gerade nicht dabei, Stichworte Union / loop und Overlay, wer sich damit auseinandersetzen will. Kommt z.B. bei der Linux-Distribution Knoppix m.W. von Anfang an zum Einsatz, um bei Verwendung eines CD-ROM (oder nur-lesbar gemounteten Images auch anderer Größe) eine Bearbeitung und Speicherung der Änderungen zu ermöglichen, über Bootsequenzen hinweg.