Würde ich auch interessieren. Eine direkte/generelle DeDup Möglichkeit gibt es bei Qnap nicht?
Eine direkte/generelle DeDup Möglichkeit gibt es bei Qnap nicht?
'türlich - doch
Screenshot 2022-03-03 172538.png
... also beim Sichern eben.
Würde ich auch interessieren. Eine direkte/generelle DeDup Möglichkeit gibt es bei Qnap nicht?
Joa bei QuTS geht das direkt auf Block ebene, aber auf QTS ist mir nix bekannt
Im Prinzip lässt sich so etwas auch recht schnell als Shellskript basteln. find liefert alle in Frage kommenden Dateien inklusive Pfad, cmp vergleicht Dateien und liefert das Ergebnis als auswertbaren Exitcode, ls -l zeigt an zweiter Stelle, ob eine Datei schon einen Hardlink hat, ls -i liefert den Inode, womit erkannt werden kann, ob Dateien bereits auf denselben Inhalt zeigen (dann ist der Inode gleich), und ln (ohne die Option -s) erzeugt einen Hardlink.
Das schnell selbstgebastelte Skript läuft allerdings nur für eine begrenzte Anzahl von Dateien gut. Da man jede Datei mit jeder anderen vergleichen muss, wächst der Zeitbedarf quadratisch zur Anzahl der Dateien, was das Skript bei vielen Dateien schnell unbrauchbar macht. Um auch große Anzahlen von Dateien einigermaßen effizient zu vergleichen, müsste man wohl vorab sämtliche Verzeichnisse einlesen, nach der Größe der Dateien sortieren und nur gleichgroße Dateien miteinander vergleichen. Dann wird das Skript aber doch einiges komplexer.
Mal ganz abgesehen von evtl. Performance Einbußen.
Ich kenne Systeme, dafür kann man einen schönen Mittelklassewagen kaufen, die bei Aktivierung von Dedup bis zu ca. 50% Performance Einbuße haben.
Und hardwaremäßig sind die Klassen höher angesiedelt als ein QNAP NAS.
Klar kann man jetzt sagen, schlechte Softwareimplementierung. Aber gerade bei QNAP ist softwaretechnisch ja auch imner alles Gold, was glänzt, oder? 
Gruss
Ich kenne Systeme, dafür kann man einen schönen Mittelklassewagen kaufen, die bei Aktivierung von Dedup bis zu ca. 50% Performance Einbuße haben.
Wenn man ein anderes System haben will und bereit ist, dafür viel Geld auszugeben, kann man auch ein Qnap-NAS mit quts-hero nehmen, mit viel Speicher ausstatten und alle Pools mit ZFS formatieren.
ZFS macht die Deduplizierung auf Dateisystemebene, und das bei genügend Speicher recht effizient. Damit besteht das genannte Problem des Threads nicht mehr. Die Dateien sind zwar weiterhin doppelt im System, aber sie nutzen keine doppelten Speicherplatz und ein Ersetzen durch Hardlinks würde nichts bringen.
kann man auch ein Qnap-NAS mit quts-hero nehmen,
"Hust" *zwinker*
Das sind mir irgendwie zuviele "wenn man" und "viel Geld" (getreu meinem Moto: lieber ein Spatz der mir in die Hand schei...., als eine Taube die mir auf den Kopf kackt)
Mal sehen was mein FileFusion-Test so bringt und am Ende an Performance-Einbußen aufzeigt. Der erste Lauf auf einem 4,5TB-Freigabeordner läuft noch; laaange 
11 Stunden später als der Screenshot oben:
Screenshot 2022-03-04 191421.png
Immerhin schon 2% "freigeschaufelt" - obwohl von Schaufeln jetzt irgendwie noch keine Rede sein kann 
Naja, in 4-5 Tagen weis ich mehr .... 
Das ganze hat auch einen Nachteil... manchmal will man Dubletten ja ganz bewusst haben. Und da fände ich es blöde, wenn beides per hardlink auf die gleichen inodes geht.
Und da fände ich es blöde, wenn beides per hardlink auf die gleichen inodes geht.
Was ist denn jetzt z.B. wenn man immer wieder Ordner mit den gleichen Template Dateien erstellt (word,excel,etc), das sind ja Duplikate und haben dann Hardlinks durch das Program.
Wenn man jezt eine der Dateien bearbeitet, bearbeitet man doch die Quelldatei...will ich in den Falle ja nicht, Muss ich ja dann neu Speichern sonst geht es schief.
Wenn man jezt eine der Dateien bearbeitet, bearbeitet man doch die Quelldatei...will ich in den Falle ja nicht, Muss ich ja dann neu Speichern sonst geht es schief.
Was dann geschieht und was man tun muss, hängt wirklich von dem Programm ab, mit dem man die Datei bearbeitet.
Viele Programme, und ich meine, da gehören Word und Excel dazu, ohne das jetzt genau zu wissen, machen sogenanntes sicheres Speichern. Da wird beim Speichern erst die ganze Datei unter einem temporären Dateinamen gespeichert, anschließend wird die ursprüngliche Datei gelöscht und dann wird die temporäre Datei umbenannt zur ursprünglichen Datei. Sinn davon ist, dass auch bei einem Programmabsturz (oder Stromausfall) während des Speicherns noch eine Version auf der Platte vorhanden bleibt. Ein Nebeneffekt ist, dass dabei der Hardlink gebrochen wird und danach zwei unterschiedliche Dateien mit zwei Verzeichniseinträgen bestehen, welche nicht verlinkt sind.
Andere Programme, wie z. B. Datenbankprogramme, schreiben die Datei nicht neu, sondern ändern die vorhandene Datei. In dem Falle zeigen danach beide Verzeichniseinträge auf die geänderte Datei, weil der Link erhalten bleibt, und die ursprüngliche Datei gibt es nicht mehr.
Man weiß also nicht, was man bekommt, wenn man eine Datei mit Hardlink ändert. Und was man möchte, ist wieder eine andere Frage. Dies ist ein Grund, warum Hardlinks außerhalb von Backup- und Archivierungszwecken außer Gebrauch gekommen sind. (Außerdem lohnt idR. der Platzgewinn den Aufwand nicht.)
Mit der Deduplizierung von ZFS hat man die Probleme übrigens nicht.
Zum Finden der Duplikate würde ich das Linux-Kommando fdupes empfehlen. (Vorausgesetzt das existiert auf dem abgespeckten QNAP-Linux.) Aus dem Output von fdupes dann ln-Kommandos zum Ersetzen der Duplikate durch Hardlinks zu generieren, ist eine reine bash-Fingerübung. Ich habe das vor ein paar Jahren mal auf einem "richtigen" Linux-Server gemacht. Bei Interesse kann ich mal schauen, ob ich noch irgendwo eine Kopie des Skripts von damals finde.
Habe mit den "verlinkten" Dateien auch ein wenig gespielt, obwohl ich gar nicht so ganz klar erkennen kann, welche nun verlinkt ist und welche ein Original ist;
Bei Hardlinks gibt es keinen Unterschied zwischen Original und verlinkter Kopie. Die beiden sind gleichwertig.
Obwohl ich das nicht verstehe; wenn ich mal tatsächliche die "Master"-Datei erwische!? Werden dann alle Links gelöscht und die die originäre Datei ersetzt?
Du hast das Prinzip von Hardlinks noch nicht verstanden.
Bei Hardlinks hat eine Datei einfach mehrere Verzeichniseinträge. Wenn ein Verzeichniseintrag gelöscht wird, dann wird in der Datei erst einmal nur der Zähler für die Anzahl der darauf verweisenden Verzeichniseinträge um eins erniedrigt. Erst wenn der allerletzte Eintrag für diese Datei gelöscht wird, wird auch die Datei selbst gelöscht und der Speicherplatz freigegeben. Dabei ist völlig unerheblich, ob dieser Eintrag das urspüngliche Original war oder als Link erzeugt worden ist, da Original und Links gleichwertig (und nicht unterscheidbar) sind.
Tatsache ist, dass es irgendwie vollkommen wurscht zu sein scheint, mit welchem Programm ich auf (in diesem Testfall eben mp3) eine Datei zugreife und ändere (audacity, PreSonus Studio, oder nur ein mp3-Tag editiere), es löst sich die Verlinkung sofort wieder auf und ist wieder eine eigenständige Datei.
Das hängt vom verwendeten Programm ab, siehe Beitrag #13. Es scheint aber so zu sein, dass die meisten modernen Programme das sichere Speichern vornehmen und damit den Link auflösen und anschließend nur ein Verzeichniseintrag die Änderung enthält.
Es gibt aber auch andere Programme, bei denen dies nicht der Fall ist, der Link beibehalten bleibt und dann alle Verzeichniseinträge die Änderung enthalten, z. B. (gerade eben ausprobiert)
- der Editor vi (der, ich gebe es unumwunden zu, nicht gerade unter moderne Programme fällt)
- der Hexeditor iHex auf dem Mac.
Man kann sich also nicht drauf verlassen, solange man sein Programm nicht kennt.
Man weiß also nicht, was man bekommt, wenn man eine Datei mit Hardlink ändert. Und was man möchte, ist wieder eine andere Frage. Dies ist ein Grund, warum Hardlinks außerhalb von Backup- und Archivierungszwecken außer Gebrauch gekommen sind. (Außerdem lohnt idR. der Platzgewinn den Aufwand nicht.)
Dem ersten Satz möchte ich zustimmen. Ich würde nicht pauschal Duplikate in Hardlinks umwandeln, wenn ich nicht genau weiß, dass das in jedem behandelten Fall auch gewollt ist.
Dem letzten Satz (in Klammern) stimme ich dagegen überhaupt nicht zu. Warum?
Ich verwende ein Backup-System auf der Basis von rsync / rsnapshot / rsnap, das jede Nacht eine vollständige Kopie des gesamten Datenbestandes von ca. 2,4 TB anlegt. 8 Nächte lang täglich, dann wöchentlich, schließlich monatlich. Und das Ganze auf ca. 10 Jahre angelegt. Bekanntermaßen werden alle unveränderten Dateien jeder Sicherung als Hardlink angelegt. Im ersten Jahr benötige ich erfahrungsgemäß für alle ca. 25 Sicherungen weniger als 3 TB insgesamt. Ohne Hardlinks wären es dagegen schlappe 60 TB. Dieser Platzgewinn von 95% lohnt sich m. E. durchaus!
Zusatz für besonders Interessierte: In meinem Falle kommt hinzu, dass es bei den Fotos schon im Primärdatenbestand etliche Hardlinks gibt. Denn ich wähle aus der Menge von erstellten Fotos für die Wiedergabe (oder Weitergabe) aus, indem ich die in Frage kommenden in ein neues Nachbarverzeichnis kopiere, und zwar als Hardlinks. Soweit ich das Programm HBS 3 verstanden habe, würde das diese Hardlinks beim Sichern aufbrechen. rsnapshot (auch über rsnap) kann man dagegen so einstellen, dass die im Original vorhandenen Hardlinks erhalten bleiben. Das finde ich prima!
Gruß
Carol
Dem letzten Satz (in Klammern) stimme ich dagegen überhaupt nicht zu. Warum?
Ich verwende ein Backup-System auf der Basis von [...]
Der Satz in Klammern bezog sich ebenfalls auf die Einschränkung "außerhalb von Backup- und Archivierungszwecken". Das war vllt. nicht ganz klar. Bei Backups ist der Speicherplatzgewinn sehr groß, und da hat man die Probleme nicht, was geschieht, wenn man eine Datei ändert, denn im Backup ändert man ohnehin nichts. Bei Backups nutze ich auch Hardlinks, aber eigentlich nur da.
Funktioniert das mit FileFusion mit den Hardlinks auf dem NAS??? Oder hat es einfach nur Duletten gelöscht?
TreeSize findet zwar Dupletten in der Netzlaufwerkfreigabe, erstellt aber keine Hardlinks (vermute weil die Dateien nicht mit PID sondern über Inode hinterlegt ist)
