Lupinhos Home

Hi

bevor ich zur eigentlichen Frage komme, noch eine nicht so wesentliche:
das Backup läuft eigentlich problemlos (täglich), aber wenn ich den Ablauf beobachte, fällt nach wie vor auf, dass zuweilen die Geschwindigkeit von mehreren hundert Files pro Sekunde absinkt auf wenige Files pro Sekunde.
Das passiert sowohl beim Einlesen der Dateien, als auch beim verlinken.
Entsprechend steigt die "geschätzte Zeit bis Ende" auf astronomische Werte von Millionen bis Milliarden Stunden. Nach einigen Sekunden, manchmal leider auch Minuten (bis hin zu 10 Minuten), steigt die Geschwindigkeit dann wieder auf normale Werte, um dann ein paar Minuten später wieder einzubrechen.
Da das backup in der Nacht läuft, kann mir das eigentlich egal sein, aber es verwundert mich einfach (es sind auch nicht immer die gleichen Dateien) und ich frage mich, ob man Windows vielleicht mehr Speicher für solche Operationen zuweisen kann, oder ähnliches?
Ich habe zwar ein paar diesbezügliche registry-hacks gefunden, scheue mich aber davor, sie auszuprobieren, bevor ich jemanden gefragt habe, der sich damit auskennt.

Nun die eigentliche Frage:
Da ich täglich ein backup mache, habe ich die Aufräumen-Option aktiviert, damit sich nicht zuviel ansammelt.
Allerdings scheint das Programm mit dem Löschen ein Problem zu haben.
Nach dem das backup fertig ist, fängt es an, alte backup-Ordner zu löschen. Allerdings ist es damit auch nach 14 Stunden noch nicht fertig geworden. Prozessorlast hat es so gut wie keine, der allozierte Speicher springt von ca. 10MB auf ca. 700MB, die dann über ca. 10 Minuten hinweg auf 10MB abgebaut werden, dann springt er wieder auf 700MB und so geht das immer weiter (wie gesagt 14 Stunden lang).
Ich habe dann das Programm beenden wollen, was er auch akzeptiert hat, d.h. die Programmoberfläche ist verschwunden, aber der Prozess hat munter weitergearbeitet (nach obigem Schema). Nach 10min habe ich ihn dann abgewürgt.
Irgendetwas scheint da nicht richtig zu funktionieren.

Spricht etwas dagegen, alte backup-Ordner von Hand zu löschen?

Hallo,
wir haben mittlerweile ein echtes Problem mit dem Aufräumen. Mit ein paar Stunden Backup-Zeit könnten wir leben (das weicht in den meisten Fällen bis zum Arbeitsbeginn am Morgen) - aber das Aufräumen dauert mittlerweile (wenn mehr als ein Backup-Eintrag gelöscht werden muss) länger als der gesamte Arbeitstag, so dass wir nach dem ersten "Anlöschen" durch HardlinkBackup die Platte vom Server entfernen (um die neue Platte für den nächsten Tag anzuschließen) und das Löschen auf anderen PC's ausführen müssen.

Um es ganz klar zu sagen: Es liegt nicht am Programm - der Explorer braucht genau so lange, vielleicht sogar noch länger. Das Problem ist, dass das Löschen jedes Hardlinks einer Datei, die mehr als (vermutlich 7) Hardlinks auf sich vereinigt, Ewigkeiten dauert. Offensichtlich muss Windows dann Informationen auf der halben Festplatte zusammensuchen, um einen solchen Hardlink sauber zu entfernen.

Es wird schon mal ein bisschen schneller, wenn man den Schreibcache der externen Platte einschaltet (Achtung: dann muss man die Platte aber auch vernünftig abmelden) - trotzdem sind diese Zeiten nicht mehr handhabbar.

Hat irgend jemand schon eine Möglichkeit gefunden, dies zu beschleunigen? Oder hat jemand Erfahrung mit anderen Dateisystemen, die evtl. drastisch schneller an dieser Stelle sein könnten (ext3/4 oder andere) und die man ggf. über samba einbinden könnte?

Zitat von martin am February 19, 2013, 10:32
Um es ganz klar zu sagen: Es liegt nicht am Programm - der Explorer braucht genau so lange, vielleicht sogar noch länger. Das Problem ist, dass das Löschen jedes Hardlinks einer Datei, die mehr als (vermutlich 7) Hardlinks auf sich vereinigt, Ewigkeiten dauert. Offensichtlich muss Windows dann Informationen auf der halben Festplatte zusammensuchen, um einen solchen Hardlink sauber zu entfernen.

Welches Betriebssystem zeigt dieses Verhalten? Hardlinks wurden mit Vista und Windows 7 deutlich verbessert, unter XP wusste das Dateisystem tatsächlich nicht, wie viele Hardlinks für bestimmte Daten vorhanden sind, ohne den gesamten Dateibestand zu durchforsten und schlicht zu prüfen, was ein Hardlink ist und worauf er zeigt. Die Shellerweiterung http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html hat einen entsprechenden Hinweis. Mit Vista und Windows 7 sollte dieses Problem allerdings behoben sein, bei mir zeigt Link Shell Extension bei einer Datei alle Hardlinks zu dieser beispielsweise direkt ohne Zeitverzögerung im Explorer an.

Wenn ihr Vista oder Windows 7 einsetzt, wie habt ihr es installiert? Womöglich als Upgrade von einem XP? Ich bin nicht sicher, was mit NTFS bei einem solchen Upgrade passiert, womöglich wäre es sinnvoll das Löschverhalten mit einem frisch aufgesetzten Windows 7 und neuem NTFS zu testen.

Zitat von martin am February 19, 2013, 10:32
Hat irgend jemand schon eine Möglichkeit gefunden, dies zu beschleunigen? Oder hat jemand Erfahrung mit anderen Dateisystemen, die evtl. drastisch schneller an dieser Stelle sein könnten (ext3/4 oder andere) und die man ggf. über samba einbinden könnte?

Samba und Hardlinks funktionieren schlicht nicht, abgesehen davon ist das Setup, wenn ihr mit Wechselplatten arbeitet, doch extrem kompliziert. Wenn ihr nicht auf Wechselplatten angewiesen seid und irgendwie zentralen Speicher habt, nutzt einfach iSCSI mit NTFS und scriptet euch etwas zusammen, das lange dauern kann. Zuerst würde ich aber ein aktuelles Betriebssystem mit aktuellem NTFS testen.

Zitat von martin am February 21, 2013, 09:34
Wir haben da verschiedene Kombinationen durch. Die Produktivumgebung läuft auf einem Server 2003 (der die Backups erstellt), wenn das Aufräumen gerade mal wieder zu lange läuft, wird es abgebrochen und manuell unter Windows 7 oder 8 ausgeführt.

Das riecht für mich nach einem Problem, weil Server 2003 eben Hardlinks noch nicht so optimal unterstützt, wie Vista+, der Server 2003 kann die neuen APIs und Strukturen in NTFS ja gar nicht korrekt befüllen. Dass die Löschung in diesem Fall lange dauern kann, würde mich also nicht wundern.

Zitat von martin am February 21, 2013, 09:34
Ich habe allerdings auch schon unter Windows 7 komplette Tests (damals mit der c't-Lösung) gemacht - zu deren Beseitigung ich dann eben auch viele Stunden gebraucht habe. Und das auf einer internen SATA-Platte, auf der nie etwas anderes als Windows 7 war. Wir könnten es auch nochmal unter Windows 8 ausprobieren (was aktuelleres haben wir leider nicht 🙂 ), aber da sehe ich wenig weiteres Potential.

Windows 8 wird nichts ändern, das ist Zeitverschwendung, man kann nur sichergehen, dass NTFS auf der Datensicherungsplatte auch tatsächlich von Vista+ erstellt und für die Sicherung Vista+ genutzt wurde und dann über die Kommandozeile oder das die Sicherung erstellende Programm löschen und Messungen durchführen. ProcMon, ProcExplorer und perfmon/Ressourcenübersicht dürften da große Hilfen leisten. Würde mich auch interessieren, mangels Hardware und vorhandenen Sicherungen kann ich aber nicht selbst testen.

Zitat von martin am February 21, 2013, 09:34
Was Samba angeht: wieso funktioniert das nicht? Es gibt doch eine ganze Menge an positiven Berichten in Verbindung mit einem NAS...

Wo denn? Wo liest man denn explizit, dass HardlinkBackup mit einem Samba korrekt Hardlinsk erstellt, es schnell ist oder was auch immer oder auch allgemeiner, dass Samba von Windows-Clients erstellte Hardlinks 1:1 auf sein Dateisystem durchreicht? Ich habe nicht einmal Andeutungen gefunden, Samba implementiert auch ältere SMB-Protokolle, bei denen ich nicht mal sicher wäre, ob die das überhaupt durchreichen und Lupinho selbst schreibt hier im Forum auch nur eher schwammig, dass wenn Samba die Befehle der Windows-API durchreicht, es gehen müsste usw. Ich denke nicht, dass es gehen wird, werde es aber mangels Zeit auch nicht testen, bevorzuge ohnehin homogene Lösungen und das ist in diesem Fall NTFS.

Zitat von martin am February 21, 2013, 09:34
Und das Setup für Wechselplatten ist mit einer passenden Benennung der Platten auch nicht wirklich kompliziert - oder man muss eben mit udev ein wenig nachhelfen. Schlimmstenfalls hätte man für 6 Festplatten 6 Backup-Setups.

Ich bezog mich auf Dinge wie Sicherung per Samba, dann aber an Clients zu löschen, wenn es per Samba immer noch zu lange dauern würde usw. Wie gesagt, Samba implementiert altes SMB, das kann eigentlich gar nicht schneller sein, als nativ, wenn gerade mal NTFS unter Vista+ hinsichtlich Hardlinks optimiert wurde, Samba zumeist XP-kompatibles SMB implementiert und damit SMB und dessen Kenntnis über Hardlinks den Flaschenhals bilden wird, unabhängig vom unter Samba liegenden Dateisystem. Meiner Meinung nach ist die Lösung, per Samba zu sichern, aber ohnehin Frickelei, insbesondere in Hinblick auf Dateieigenschaften, ACLs, Streams usw., alles Murks, weil die Unterstützung stark von der korrekten Konfiguration von Samba abhängt oder manche Sachen gar nicht vernünftig abgebildet werden.

Zitat von martin am February 21, 2013, 09:34
Bevor ich nun aber eine unserer Sicherungsplatten mit richtig vielen Dateien und den ganzen Hardlinks auf eine ext4-formatierte Platte umsetze und dafür einige Stunden Zeit investieren müßte, bin ich doch an Berichten von Leuten interessiert, die so einen Vergleich schon einmal gemacht haben.

Ich würde gerade die vorhandenen Platten erst mal hinsichtlich der Version von NTFS untersuchen, um sicher zu gehen, dass auch die neuere von Vista+ genutzt wird, und dann Dinge tun wie, die oben genante ShellExtension installieren und gucken, wie schneller der Windows Explorer alle Hardlinks einer Datei anzeigen kann. Beides womöglich sogar unter Server 2003 und Windows 7, müsste in jedem Fall einen Unterschied geben, wenn nicht, wird altes NTFS verwendet und das bildet dann den Flaschenhals. Der Datenbestand kann dann auch gleich für Tests mit neu unter Windows 7 formatierten Festplatten herhalten, wobei ich gerade nicht sicher bin, wie man den Datenbestand am besten auf die neue Platte spiegelt. Ich glaube robocopy und Co. erzeugen keine neuen Hardlinks, Images darf man wg. der alten NTFS-Version natürlich auch nicht wiederherstellen. Alles nicht so einfach. 🙂

Zitat von martin am February 21, 2013, 09:34
Ok - die Sicherung neuer Dateien wäre über iSCSI sicher deutlich schneller als über USB 2.0, aber das Verlinken und Aufräumen?

Ob iSCSI schneller ist oder nicht, hängt ja von euren Dateien ab, wenn USB 2.0 gar kein Flaschenhals ist, wird iSCSI auch nicht soo viel schneller sein. Ich habe es nur als Alternative zu Samba erwähnt, wenn es um Dinge wie zentralen Speicher und Co. geht, weil ich eine Sicherung auf NTFS immer bevorzugen würde.

Zitat von martin am February 25, 2013, 12:13
Wie ich schon geschrieben habe: es war ein unter Windows 7 komplett neu eingerichteter Rechner und die Sicherung auf der internen Platte - die hat nie ein älteres System als Windows 7 gesehen. Und auch da hat das Löschen ewig gedauert - egal mit welcher Software die Hardlinks erstellt wurden (HardlinkBackup oder die Original-ct-Lösung)

Ich habe seit gestern mal eine Backupstruktur mit 100 Ordner mit jeweils 5000 Dateien erstellt und diese in bis jetzt 10 Generationen verlinkt, also viele Dateien, aber erst mal nur wenige Hardlinks. Gelöscht über den Windows Explorer dauert das ganze vielleicht 10 Minuten und der Windows Explorer zeigt an, dass er ca. 1000 Elemente pro Sekunde löscht. Das sieht nicht soo langsam aus, geht auch über USB 2, mein Rechner ist relativ alt und ich habe sogar noch TortoiseSVN laufen, was alle möglichen Explorer-Operationen verlangsamt.

Zitat von martin am February 21, 2013, 09:34
Ok, ich habe mir gerade mal die Lösung mit dem nachträglichen Script angesehen, die HardlinBackup erstellt. Sieht gar nicht schlecht aus, sollte unter jedem Standard-Linux laufen und würde unseren Hauptserver beim Verlinken entlasten. Ich weiß jetzt nicht, wie es mit dem Aufräumen aussieht - ob HardlinkBackup auch dafür ein passendes Script erzeugt? Denn das dürfte in jedem Fall ja erst nach der Verlinkung stattfinden.

Und wie funktioniert das dann, nachträglich verlinken auf einem Linux unter Umgehung von Samba oder was genau meinst du?

Zitat von martin am February 21, 2013, 09:34
Und der Test mit der Shell-Extension ist sicher interessant - allerdings reden wir pro Datei von Zeiten unterhalb einer Sekunde (aber eben sehr unterschiedlich unterhalb einer Sekunde), so dass die Anzeige der Hardlinks einer Datei sich nicht auffällig unterschieden wird.

Genau das ist falsch, Server 2003 und Co. wissen schlicht nicht, zu welcher Datei es Hardlinks gibt und müssen deswegen die komplette Platte durchsuchen. Das würde man also sehr schnell merken.