Beiträge von michaelxy

Habe es gerade gesehen, in der 4.3.5 kann ich es verkleinern Problem erledigt. Es hat verkleinert und ich arbeite nun mit der realen Größe.

Habe bei der Neueinrichtung die mehr oder weniger verständlichen qnap Anweisungen befolgt und in meinem 2,7 TB Raid1 - (1)40% über. abboniert - oder wie das auf Denglisch / qnap-Sprache sich nennt. Freilich wollte ich das nie, aber das Setup war recht idiotisch zu verstehen und das kam dabei raus. Ich arbeite mit PCs wie Speichern schon seit 30 Jahren.

Jedenfalls die Frage, ob man das jetzt nie mehr wieder auf die reale Größe bekommt?

Ist das bestätigt oder nur Forengeschwätz, daß ein einmalig überabboniertes Volumen irreversibel 'falsch' eingerichtet bestehen bleiben muß?

Danke Dir - dann ist es doch so komplex und "normal". Die Idee vom 2. Volume war die, da hier nur image-Backups landen, dafür keine snapshotspeicher opfern zu müssen. Ich denke, daß die Deltas bei dem GB großen Acronis Images, oder exports via NFS vom esxi (~300 GB in Summe) wohl den snapshotplatz schnell hätten geschrumpft - wenn ich das so richtig verstehe.
So gibt es vom anderen volume (mit relevanten Office etc-Daten) nun 1x täglich einen Snapshots und davon max 180. Aber wenn das System so flexibel ist, dann ist es ja gut. Allein, daß man die volumes scheinbar nicht verkleinern kann, ist unpraktisch.

Meine TS-251 mit 4.3 zeigt mir wirre Speichergrößen an. Obwohl max 2,72 TB verfügbar hätte ich 2,26+1,15. Habe ich das Konzept der dyn./thin prov Speicher nicht verstanden?

Siehe Anhang.

Grüße
Michael

Oh - peinlich - mea culpa. Kaum war die vm mit w7 aus - schon war heile Welt. Im Taskplaner war von Treesize noch ein Task hinterlegt, der eine tägliche Statistik der Freigaben erstellt.

Aber: Dieser Task wurde am 12.4. erstellt und zu dem Zeitpunkt lief laut der Auswertung alles normal. Es kamen auch nicht wirklich neue Dateien dazu, daß treesize hätte mehr scannen müssen - bzw war der scan von treesize nie ein CPU Problem. Windows-Updates gab es für w7 zu dem Zeitpunkt/wurden eingespielt nicht. Ich meine auch kein Firmwareupdate der NAS.

Ähnliches gab es mal mit robocopy, da stieg die NAS CPU bei einer Sicherung auch hoch - dafür gab es einen Hotfix für Windows 7. Ggf geht es in die Richtung. Jedenfalls ist die primäre Ursache gefunden. merci.

3 echte PCs waren schon offline. Sonst gibt es nur die Fritzbox, 2 IP Tel, 2 Raspi. Wie gesagt, per tcpdump gibt es da keinen traffic. Blöd, daß man da bei Samba scheinbar keinerlei Analyse-möglichkeiten hat. Kann man aus dem trace irgendetwas erkennen?

Wenn ich Zeit habe, trenne ich wirklich mal die NAS vom Netz ab.

Der Inhalt der strace...log bringt mich nicht wirklich weiter. Anbei ein Ausschnitt und die Muster wiederholen sich. Der Amok-smbd Prozeß lief erst unter admin und dann unter meinem Benutzer xyz mit selber PID. xyz ist auf der NAS als Benutzer angelegt. via tcpdump sehe ich keinen großen Netzwerk-Verkehr. Die Kiste scheint eher mit sich selbst beschäftigt.

open("/etc/config/smbpasswd", O_RDONLY|O_LARGEFILE) = 43
rt_sigaction(SIGALRM, {0xb6926dbc, [ALRM], 0x4000000 /* SA_??? */}, {SIG_DFL, [ALRM], 0x4000000 /* SA_??? */}, 8) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={5, 0}}, {it_interval={0, 0}, it_value={0, 0}}) = 0
fcntl64(43, F_SETLKW64, {type=F_RDLCK, whence=SEEK_SET, start=0, len=1}, 0xbebf59e0) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, {it_interval={0, 0}, it_value={4, 998562}}) = 0
rt_sigaction(SIGALRM, {SIG_DFL, [ALRM], 0x4000000 /* SA_??? */}, {0xb6926dbc, [ALRM], 0x4000000 /* SA_??? */}, 8) = 0
stat64("/etc/config/smbpasswd", {st_mode=S_IFREG|0600, st_size=626, ...}) = 0
fstat64(43, {st_mode=S_IFREG|0600, st_size=626, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb55b3000
read(43, "admin:0:XXXXXXXXXXXXXXXXXXXXXXXX"..., 4096) = 626
rt_sigaction(SIGALRM, {0xb6926dbc, [ALRM], 0x4000000 /* SA_??? */}, {SIG_DFL, [ALRM], 0x4000000 /* SA_??? */}, 8) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={5, 0}}, {it_interval={0, 0}, it_value={0, 0}}) = 0
fcntl64(43, F_SETLKW64, {type=F_UNLCK, whence=SEEK_SET, start=0, len=1}, 0xbebf5b48) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, {it_interval={0, 0}, it_value={4, 999301}}) = 0
rt_sigaction(SIGALRM, {SIG_DFL, [ALRM], 0x4000000 /* SA_??? */}, {0xb6926dbc, [ALRM], 0x4000000 /* SA_??? */}, 8) = 0


....


cntl64(22, F_SETLKW64, {type=F_RDLCK, whence=SEEK_SET, start=264, len=1}, 0xbebf5a10) = 0
fcntl64(22, F_SETLKW64, {type=F_UNLCK, whence=SEEK_SET, start=264, len=1}, 0xbebf5a68) = 0
fcntl64(21, F_SETLKW64, {type=F_RDLCK, whence=SEEK_SET, start=264, len=1}, 0xbebf5a10) = 0
fcntl64(21, F_SETLKW64, {type=F_UNLCK, whence=SEEK_SET, start=264, len=1}, 0xbebf5a68) = 0
lstat64("/usr/local/samba/var/run/winbindd", 0xbebf2680) = -1 ENOENT (No such file or directory)
geteuid32()                             = 500


...


chdir("/share/MD0_DATA/images")         = 0
stat64(".", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
stat64("/share/MD0_DATA/images", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
stat64("backup/pc-michael/lotus/license/deutsch.rtf", {st_mode=S_IFREG|0770, st_size=22742, ...}) = 0
getxattr("backup/pc-michael/lotus/license/deutsch.rtf", "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x07\x00\xff\xff\xff\xff\x02\x00\x07\x00\x00\x00\x00\x00\x02\x00\x07\x00\xf4\x01\x00\x00\x02\x00\x00\x00\xf7\x01\x00\x00\x02\x00\x00\x00\xfe\xff\x00\x00\x04\x00\x07\x00\xff\xff\xff\xff\x10\x00\x07\x00\xff\xff\xff\xff \x00\x00\x00\xff\xff\xff\xff", 132) = 68
fcntl64(22, F_SETLKW64, {type=F_RDLCK, whence=SEEK_SET, start=240, len=1}, 0xbebf5b68) = 0
fcntl64(22, F_SETLKW64, {type=F_UNLCK, whence=SEEK_SET, start=240, len=1}, 0xbebf5bc0) = 0
fcntl64(21, F_SETLKW64, {type=F_RDLCK, whence=SEEK_SET, start=240, len=1}, 0xbebf5b68) = 0
fcntl64(21, F_SETLKW64, {type=F_UNLCK, whence=SEEK_SET, start=240, len=1}, 0xbebf5bc0) = 0
lstat64("/usr/local/samba/var/run/winbindd", 0xbebf27d8) = -1 ENOENT (No such file or directory)


...


chdir("/share/MD0_DATA/Dokumente")      = 0
stat64(".", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
stat64("/share/MD0_DATA/Dokumente", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
stat64("backup/Prius life ZVW30L-AHXEBW(2A)/Doku/wiki/Kurbelwellen-Startergenerator \342\200\223 Prius Wiki-Dateien/commonPrint.css", {st_mode=S_IFREG|0770, st_size=4482, ...}) = 0
getxattr("backup/Prius life ZVW30L-AHXEBW(2A)/Doku/wiki/Kurbelwellen-Startergenerator \342\200\223 Prius Wiki-Dateien/commonPrint.css", "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x07\x00\xff\xff\xff\xff\x02\x00\x07\x00\x00\x00\x00\x00\x02\x00\x07\x00\xf4\x01\x00\x00\x02\x00\x05\x00\xf5\x01\x00\x00\x02\x00\x00\x00\xf7\x01\x00\x00\x02\x00\x00\x00\xfe\xff\x00\x00\x04\x00\x00\x00\xff\xff\xff\xff\x10\x00\x07\x00\xff\xff\xff\xff \x00\x00\x00\xff\xff\xff\xff", 132) = 76
fcntl64(22, F_SETLKW64, {type=F_RDLCK, whence=SEEK_SET, start=252, len=1}, 0xbebf5b68) = 0
fcntl64(22, F_SETLKW64, {type=F_UNLCK, whence=SEEK_SET, start=252, len=1}, 0xbebf5bc0) = 0
fcntl64(21, F_SETLKW64, {type=F_RDLCK, whence=SEEK_SET, start=252, len=1}, 0xbebf5b68) = 0
fcntl64(21, F_SETLKW64, {type=F_UNLCK, whence=SEEK_SET, start=252, len=1}, 0xbebf5bc0) = 0
lstat64("/usr/local/samba/var/run/winbindd", 0xbebf27d8) = -1 ENOENT (No such file or directory)
geteuid32()                             = 500
getegid32()                             = 100


...

>Wann genau ist die CPU-Last?
14:00 - 17:30

>Immer zur gleichen Zeit?
Ja.

>Jeden Tag oder wöchentlich?
jeden Tag

>Wie sieht es aus mit:
>Virenscan
Nein - deaktiviert. Client Virenscan kann auch nicht sein, weil ist auch, wenn Clients vom Netz.

>RAID Scrubbing
Hat wohl wenig mit dem smbd Dienst zu tun. Platten sind ok.

>Indexierung von Qsirch, Photostation etc.
Nein.

>Kannst Du das Systemprotokoll posten.
Das gibt nichts her.

>Welche Dienste und Apps sind aktiv?
Das Übliche - eher wenige als mehr. Wie gesagt, mit selber Config lief die schon Jahre normal.

>Welche Firmware?
4.2.6 die vom 2017/09/05

Ich bräuchte paar tipps und Linux Befehle um zu wissen, was der smbd Dienst da tut.

Angefangen hat das in KW31

Seit 2 Monaten habe ich Punkt einer genauen Uhrzeit eine hohe CPU Last und das 2h lang. Auch wenn andere PCs aus sind. Auch ist kein cronjob auf der NAS für diese Uhrzeit zu sehen auch sonst wüßte ich nichts, was da läuft. Die Sicherung auf die externe USB-HDD ist morgens und das sicher ohne smb.

Der SMB Dienste scheint irgendwie 2h mit sich selbst beschäftigt zu sein.

Wie bekomme ich genau heraus, was Samba da treibt? Die Logs per Browser geben nichts her. tcpdump ist nicht installiert ... Ich denke es ist irgendetwas lokales. Kenne ich von Samba eigentlich so nicht. Habe an der Konfig und am Netzwerk ~eigentlich~ auch nichts geändert.

Plattenzuwachs bei hoher Samba-CPU Last ist auch nicht zu beobachten - daß ggf ein Netzwerkgerät da etwas drauf schreiben will.

Grüße
Michael

Zitat von "chri$$or"

wir wäre es als Alternative mit dem rsnap plugin ?

Ja - aktuell alternativlos. Das nutzt halt rsync und legt dann wohl doch viele Dateien/links auf der qnap an. So etwas im Dateisystem integriertes fände ich ganz nett. Aber wahrscheinlich lassen sich da auch nicht wirklich die Parameter so fein justieren wie bei rsnap. Wobei die Frage ist, auf welcher Technik das snapshot-Konstrukt von QNAP basiert - oder es lediglich auch nur rsync nutzt

Ich will (...) allein per QNAP Nas Dateien per ftp/webdav nach extern AES-xxx verschlüsselt regelmäßg weg sichern.

Wie es scheint, gibt es da wohl nichts auf der QNAP onboard, was das könnte. (Firmware 4.2)

Ginge so was vielleicht ohne Bastellösung (tar + gpg + cronjob) + RRTR

Grüße
Michael

Ich denke, daß es eher eine Marketing-Entscheidung zugunsten der teureren NAS war. Die NAS muß ja nicht gleich Deduplizierung beherrschen, aber ein wenig snapshoting wäre schon ganz ok.

Weiß jemand, ob man diese snaphots unter Windows via Rechtsklick - Vorgängerversionen erreichen kann?

Die preiswerteste NAS die das könnte läge dann wohl bei ca 300€ (ohne Platten)

Der Support sagt:

"Die Schnappschuss-Funktion gilt nur für die folgenden NAS-Modelle: TS-269L, TS-269 Pro, TS-469 Pro, TS-469L, TS-469U-RP, TS-469U-SP, TS-470 Pro, TS-470, TS-569 Pro, TS-569L, TS-669 Pro, TS-669L, TS-670 Pro, TS-670, TS-869 Pro, TS-869L, TS-869U-RP, TS-870 Pro, TS-870, TS-870U-RP, TS-879 Pro, TS-879U-RP, TS-1079 Pro, TS-1269U-RP, TS-1270U-RP, TS-1279U-RP, TS-1679U-RP, TS-EC879U-RP, TS-EC1279U-RP, TS-EC1279U-SAS-RP, TS-EC1679U-RP, TS-EC1679U-SAS-RP, SS-EC1279U-SAS-RP, SS-EC1879U-SAS-RP, SS-EC2479U-SAS-RP, TS-EC2480U-RP, TS-EC1680U-RP, TS-EC1280U-RP, TS-EC880U-RP, TS-EC1080 Pro, TS-EC880 Pro, TVS-471, TVS-671, TVS-871, TVS-871U-RP, TVS-1271U-RP, TVS-463, TVS-663, TVS-863, TVS-863+."

>Aber warum nur für diese Modelle, kann uns einer aufklären?
Die ARM CPUs sind wesentlich langsamer als x86 CPUs - vielleicht deshalb. Bei manchen netapp storages z.B. tut solches aber auch nur ein Dual-x86-Atom-CPU. SO viel CPU-Leistung dürfte das nicht kosten. Kann es aber technisch nicht abschätzen.
Vielleicht wollte man sich einfach auch nur die Programmierarbeit sparen und marketingtechnisch mal schnell etwas von snapshots sprechen.

Snapshots sollten aber zu jeder NAS gehören. Bei Windows geht das schon ab Vista... (Vorgängerversionen)
Ginge wohl auch per iSCSI und einer NTFS Partition - aber iSCSI ist nicht für Multiuser (meines Wissens) vorgesehen.

>Und wird "Snapshot" noch für weitere Modelle frei gegeben?
Man müßte bei qnap selbst anklopfen - ob.

Hallo

es wurde ja die QTS 4.2.0 (letzte Version) sehr stark beworben - darunter auch (endlich) die Möglichkeit, snapshots erstellen zu können.

Also nach der Anleitung verfahren:

https://www.qnap.com/i/en/tuto…ow.php?op=showone&cid=139

Allein die Option zur Eingabe der % für die snapshot Reserve fehlt

Warum gibt es die Option nicht ?
Wenn überhaupt - für welche QNAP NASen soll es diese snapshot-Option überhaupt geben?

Grüße

Die GUI muß scheinbar an das Niveau der Unser angepaßt werden. Also so idiotensicher wie möglich. Wohl vielleicht auch deshalb rücken technische Dinge bei QNAP eher in den Hintergrund.

Synology scheint es zu können:

"Kohärentes und effizientes Backup: Synology Snapshot-Manager, das neue Software-Plug-in für VMware® vSphere™ und Windows®, bietet anwendungskonsistente Snapshots und gewährleistet damit die Konsistenz der Daten. Die Integration inkrementeller Backup-Technologien auf Block-Level für mehrere Backup-Versionen erhöht die Speichereffizienz enorm."
aus http://www.wilkon.de/1545.html?&MP=797-1522

Was immer genau "PlugIn" bedeuten mag.

Ich würde mutmaßen, daß es wohl noch nicht ordentlich funktioniert hatte, sonst hätte man sich so ein Kauf-Argument nicht entgehen lassen. Oder der 0815-User benötigt es nicht. Oberste Priorität einer NAS ist das sichere speichern, ggf war es den Herstellern zu heikel. What ever.

Servus,

Zitat

SAMBA bot schon seit mehr als 5 Jahren die Funktion der Schattenkopien wie bei Windows,

Ging irgendwie an mir vorbei :oops:

Zitat

und dieser ist inzwischen in der SMB-Firmware integriert.

Ohne dem, hätte man im SMB-Bereich wohl auch schlechte Karten. Wenn Samba das anscheinend sowieso schon kann, wundert es mich nun doch, warum das so lange dauert.

Zitat

Da die Snapshots in der QTS 4.2 auf LVM aufbaut (die Anleitung wurde von QNAP wieder entfernt), wird es auch mit SAMBA möglich und somit auch für Windows über die Freigabe erreichbar sein.

Das wäre eine feine Sache die mich frühlingshaft erfreuen würde.

Zitat

Zusätzlich wird es mit der QTS 4.2 eine Snapshot Funktion geben.

Für die Funktion wird es aber auch wirklich einmal Zeit... Apple Jünger hatten bereits - meines Wissens - diese Zeitmaschinenfunktion auf der NAS, wobei Apple-Anwender der NAS wohl eine kleine Minderheit darstellen.

Ich hoffe das snapshotting funktioniert auch auf Windows-Freigaben und mit einer flexiblen Einstellung der Vorhaltezeit. Es muß nicht gleich auf dem Niveau einer NetApp sein.

Das Design ist mir da relativ gleich, wenn es nicht zu unübersichtlich würde. Mit der Suchfunktion kann man ja schnell die Einstellungen finden.

Des Lösungs Rätsel kommt per Hotfix KB2646535 mit. Hier bekommt man eine neue ntfs.sys und robocopy.exe. Letztere kennt den Parameter /NOCOPY und diese macht das nun endlich wieder normal schnell. Der Fehler scheint wohl eher bei Microsoft zu liegen. Der Witz ist, daß Robocopy selbst unter w7 in Verbindung mit deren Server 2008 langsamer wird... Made in USA halt.

Ich dachte schon ich wäre blemblem. Ist bei mir auch so mit der neusten Firmware. Lange genug suchen tut die NAS eigentlich schon ... Es muß ggf mit den Rechten zusammen hängen. In einem anderen Ordner der für jeden Schreib-und Leserechte hat, hat er Bilder indexiert. In einem anderen Ordner der selben Freigabe fehlen so gut wie alle Bilder. Höchst Dubiös.