ullibelgie

Irritierend ist ja, daß das Script log am Ende sagt, das beim zweiten Backup der original Datei nichts übertragen und geschrieben wurden auf dem Ziel. Das wäre ja auch richtig, da an der Quelldatei nichts verändert wurde. Aber tatsächlich ist auf dem Ziel Ubuntu PC alles neu geschrieben worden. Habe nochmals überprüft: - beim Einfügen des script keine versehentlichen windows line-feeds, sondern correct Unix-LF benutzt - Am Zielrechner das smb.conf file enthält unter Global - Networking, die nicht auskommentierte Zeile unit extensions = yes - Im Terminal mit Befehl "testparm" überprüft, daß keine fundamentalen (Syntax-)Fehler im smb.conf stecken Also ich weiss leider nicht wo ich jetzt weiter suchen soll. Habe es nochmals ausprobiert - ohne Erfolg - immer jedes Backup genauso gross wie die Quelldatei...

Ich habe auf dem Zielrechner (Ubuntu 20.04LTS) im smb.conf controlliert: Unter Global Networking ist sehr wohl folgender Eintrag aktiv: Unit extensions = Yes Das kann es also nicht sein - leider. Wäre einfach gewesen... Es muss aber irgendwas anderes sein.

Hallo, leider war ich umständehalber eine zeitlang nicht mehr mit Unraid beschäftigt - es fehlte die Zeit und der Server stand ein paar Monate still. Jetzt habe ich mich wieder etwas eingearbeitet und will eine Backup-Lösung einrichten für die Unraid Daten und Systemfiles. Hierzu wollte ich eigentlich das Script von MGutt nutzen aber es will nicht so recht funktionieren. Folgendes habe ich getestet: Ein Testfolder mit einigen Dateien van ca 5Mb soll auf einen externen Linux PC (Ubuntu 20.04LTS) gesichert werden Die HDD vom Zielrechner ist mit dem Plugin 'unassigned devices' in Unraid gemounted und die URL im Backup Scipt vers. 0.6 auch als Ziel angegeben Ich führe das Script auf Unraid im Hintergrund laufend aus mit dem Script Plugin 'User scripts' aus - das funktioniert prima und die Daten werden auch auf der HDD des Zielrechners geschrieben. So weit alles gut - aber: Wenn ich das script nochmal ausführe ohne den Quellordner irgendwie geändert zu haben, wird wieder alles in voller Grösse geschrieben und die frisch formatierte ext4 HDD hat jetzt doppelt so viel Speicher beschrieben wie der Quellordner gross ist (also kein incrementelles Backup) Wenn ich das script dann 5x ausführe immer mit dem gleichen Ordner ohne Anderungen, kann ich mit du -d1 -h /url Zielordner | sort -k2 genau sehen, das eben 5x die 5Mb vom Test-Quellordner geschrieben sind und die neue Platte eben 25Mb neue Daten hat. Das scheint mir nicht zu sein, wie es sein sollte ! Zur Kontrolle habe ich mal mit rsync manuell: rsync -avh "quellordner" "zielordner" mehrere Male ausgeführt mit dem korrekten Resultat, dass der Ordner nur einmal über das Netzwerk auf den Linux-Rechner gespielt wird und die Daten nicht mehrfach in voller Grösse übertragen und geschrieben werden (Dupes!) Allerdings: Wenn ich mit dem Script von MGutt innerhalb des Unraid servers auf einen Zielordner ein "Backup" machen lasse und eben nicht über das Netzwerk (einfach von einem Share auf einen anderen Share in Unraid), dann funktioniert die Sache und der Folder wird nur einmal in voller Grösse geschrieben. Man sieht das nur das erste Backup die Originalgrösse hat und alle anderen Backups viel kleiner sind. (so wäre es korrekt!) Was mir auch aufgefallen ist bei der Ubertragung des 2ten.3ten, 4ten Backups (immer mit demselben Ordner uber das Netzwerk): Im Log wird ab dem 2ten Backup gesagt das nichts übertragen/geschrieben wurde, aber tatsächlich waren alle Daten doch in voller Grösse doppelt und dreifach geschrieben worden - es scheint also, als ob das Script log nicht übereinstimmt mit der Realität. Was kann hier die Ursache sein - was müsste ich evtl mal uberprüfen um das Script doch richtig zum Laufen zu bringen um von Unraid auf ext4 formatierte Platten nach Ubuntu zu sichern. Leider habe ich es nicht fertiggebracht die HDD in xfs unter Ubuntu zu formatieren - hier ist vielleicht die Ursache im anderen Filesystem zu suchen ? Hat schon mal jemand wirklich getestet ob das Script läuft auf Zielmedien von ext4 Platten - hier sollten Hardlinks eigentlich unterstützt werden, aber ich habe inzwischen meine Zweifel... Oder muss ich in Samba auf dem Zielrechner irgendwas einstellen was bisher fehlt (.conf file) Vielen Dank für ein paar gute Tips zu dem Script.

Meine Ubuntu Version is 20.04 LTS

"But if you did the format before assigning it to the array, then the format you did, though pointless, wouldn't have been a problem. I say pointless because rebuild is going to overwrite the entire disk, including any format you did." Thanks for explanation - I was not aware, that there is no need to format the disk.... but I am just a stupid user of computer applications until I started with Unraid a few weeks ago. I am depending on people like you who explain to me how things work and I try to read as much as possible about it... "So, if you format a disk in the array and then rebuild it from parity, the rebuild can only result in an empty filesystem." This is clear to me now, but it is not what I have done - the disks were formatted before they were assigned to the Array - useless though... But thanks for the warning ! "Also note that if you pre-clear a disk, then format it as you did, it is no longer clear. So if you add that disk to a new slot in the array, Unraid must clear it again so parity remains valid." Another reason not to format a disk in the replacement process So you can see, that even there is a extensive wiki available, which I at least have read 10times, you still can misunderstand a lot with no IT-background at all... we call it learning...;-) I did not expect my server to last longer than one month.... I almost reached it, before it breaks... Now it is time to do it again, I think - I still have the old data-disk, which contains the files of Disk 1, which I now moved partly to lost&found... so I can recover it, I hope

Clean re-install: I am using Unraid as a simple NAS - just a fileserver plus two applications: Paperless-NG and Calibre Recently I had to repair XFS file system on one of my Data-disks. Result is, that 360Gb of data is moved in the lost&found folder. As this is from moved from all shares (incl. Appdata, system, etc...) to the lost and found folder, I am dependent on this folder and cannot this 360GB of mess (partly unreadable) So I want to make a clean re-install without a need for a 360GB Lost & Found Erase all shares and build them new - possibly by uploading 100000 files or more with rsync from offline data storage... Do I need to erase and reformat the disks as well ? I am just looking for a safe procedure to erase the large lost & found-folder

I followed the procedure of the Unraid wiki for taking out disks to replace them with bigger ones. Every new disk needs to be formatted - that is, when Unraid sees the new hardware for the first time and place it in the unassigned disk plug-in. Here I pre-cleared the new disks (stress test for 2days) then formatted them in XFS After that assigned them in the disk array, so at that moment the rebuild process started and finally finished with zero errors... Then I switched off the Server in the evening to switch it on next morning with the new Data disk being unmountable After XFS_Check and XFS_repair, I end up with half of the data moved from Data Disk 1 to Lost & Found folder The problem is that for example files which have been before in "Audio" share, have been moved to "Lost & Found" and are not in the Audio share anymore... In total this in total 360Gb moved from all shares (incl system, AppData....) to lost and found and many are unreadable... I don't know how to correct this -- rather than build a new server ... copy & paste for weeks from offline data files.... no real server backups, just the original data at it original place had not (yet) been erased, as the server is only about 4weeks old...

I recently had a lot of hardware problems, which made xfs_filesystem repairs necessary. So I end up with hundreds of GB Lost & Found file/share, with the moved data, due to the failures. I think the problems are because my server is rather old hardware and the timer in disk settings for waiting before shutdown, was improperly short set to only 90sec. Although I am not running any VM's and normally close dockers manually and stop the disk array manually before pushing the shutdown button in Unraid web-gui, it may be not shutdown correctly and therefore caused the problems... I now consider a clean new install of my total Unraid server. I have recent backups of: - USB -stick - AppData folder - external Paperless-NG folder consisting of all documents for this app - Ebooks with Calibre database - all other data is still available offline as well So how to do a clean reinstall ? The unraid Wiki explains the steps for 'getting started'.... but I want to 'get re-started' - that could be a difference as the disks are not empty Also: How do I manage the Unraid OS plus license ? Should I start the USB stick with the .zip backup instead of the clean Unraid OS software ? Please advice the best way for a clean re-install of the server I do not want to keep the mess, which has occurred with 360Gb of Data moved to lost and found with lots of data even unreadable Many thanks...

I think I know the reason for the XFS - file system problems: My machine is a very old hardware and slow. However the disk settings for wait until shutdown is only 90sec. It could be, that this timing is too short to guarantee a clean shutdown under normal circumstances, because the server hardware is old and rather slow... So I increased the timer now to 600sec to be save and to prevent a unclean shutdown... I am considering to rebuild the total server with a new clean install - all data I have offline ...

Nachkontrolliert mit dem angegebenem Befehl - alle Backups sind immer gleich gross und so gross wie das erste Backup...wie vermutet Was ist hier bloss faul mit meinen Einstellungen ?

"Wie hast du das verifiziert?" Am Ubuntu client muss ich ja im Terminalfenster das Backup-script aufrufen und ausführen - bei mir heisst das dann 'unraid.sh' bei Eingabe im Terminalfenster von Ubuntu gebe ich also ein: ./unraid.sh Das script fragt dann seine incremental file list an beim Server und dann sehe ich alle files, wie sie im Terminal Fenster nach und nach kopiert werden und dabei durchscrollen - das dauert dann so ca 15min fur die 50Gb Aber jedes Mal wenn ich das Script auf dem Ubuntu client neu aufrufe (ohne bei den Quelldateien irgendwas zu ändern) dauert es wieder die 15min mit dem durchscrollen aller FIles, die kopiert werden, aber nicht geändert wurden. Ich würde erwarten, dass das Script sagt - keine neuen Files - dann brauche ich auch nicht zu kopieren - genauso wie es beim manuellen ausführen von rsync passiert (s.u.) Denn mache ich den Kopier/Backupvorgang mit rsync manuell mit: rsync -avh "source-folder" "destination-folder" dann scrollt die File-liste nur einmal (beim ersten mal!) durch das Terminalfenster. Führe ich dann denselben Befehl mit denselben Quell- und Zielfoldern noch einmal aus, scrollt uberhaupt nix mehr durch, da ja alle Files bereits im Zielordner vorhanden sind. Ich dachte, daß müsste bei einem korrekten incrementellen Backup mit dem Script genauso sein - dass eben nicht die Files die alle kopiert werden wieder 15min lang durch das Terminalfenster scrollen und schliesslich mit 15867 files kopiert zum Schluss kommen... Inzwischen habe ich versucht Abhilfe zu schaffen, durch im /etc/samba/smb.conf file in Ubuntu unter [global] die Zeile unix extensions = yes einzufügen mit anschliessendem restart des samba service auf dem Ubuntu client... Keine Anderung... Wohlgemerkt: Ubuntu holt mit nur Lese-Rechten die Files vom Unraid server via Samba ab... Hierzu habe ich alle benötigten Folder vom Unraid Server im Ubuntu client gemounted und die Quell und Zielfolder angepasst. Das ist ja etwas anderes als ein lokales Backup auf dem Unraid server zu machen , wo Quell und Zielordner auf demselben Server liegen...

I still have the old drive and unchanged since I have taken it out. This disk had a few read errors before but was not disabled. I never had to xfs_repair the old disk.

tja, mir scheint auch langsam das es wohl ein Hardware Problem gibt mit den USB porten Ich habe jetzt die XFS formatierte USB platte lokal am Ubuntu PC angeschlossen - das funktioniert tadellos. Dein Script habe ich lokal am Ubuntu PC aufgerufen und hole mit mit read-only Rechten die Daten ab, die ich vom Unraid server auf der USB Platte sichern möchte - funktioniert prima und ohne Unterbrechungen (ca 50Gb Daten) Allerdings habe ich ein Problem: Wenn ich das Script nach erfolgreichem Backup auf dem Ubuntu nochmals ausführe , dann werden alle Daten offenbar noch einmal kopiert, obgleich die Daten dieselben sind. Habe ich eine Einstellung vergessen, die verhindert, dass incremental backups erstellt werden ? Die Unix Extensions habe ich in der Samba Einstellung auf Unraid herausgenommen, da das bei Ausführung des Scripts auf dem Ubuntu client doch nicht nötig ist - oder hatte ich das verkehrt verstanden ?

I use XFS file system for all drives To clearify: "If you are happy to lose the 320GB that was put there by the repair process then you can simply delete it and remove the share. " What does it mean ? Of coarse I do not want to loose data, but I also do not want to store data twice. The data should be in the original folders, but not somewhere in lost and found. So what I need to know: Has the repair process as a result of the repaired file system moved the data from it's original folder to lost and found ? As the lost & found file contains 1926 objects, 1874 directories and 52 files it would be a very cumbersome process to find out... What would you do ?

I recently changed my Parity disk for a bigger one and after that changed one of my data disks to a bigger one as well. I followed the guide in the Unraid wiki for doing that and although it took a very long time (3 days and nights) all went find with no errors. So at the very end, when everything was finished fine, I switched off the server safely - I stopped the array followed by the shutdown button in Unraid. When I wanted to restart the server the next morning, my newly installed (bigger) data disk was unmountable, but not disabled. Pre-clearing, formatting and rebuild process was without any error however before. I was wondering how that can happen....!?! So finally after reading a lot in forum and Unraid wiki documents, and still not understanding why the brand new HDD is unmountable, I decided to check the filesystem and finally run the repair routine... Fortunately the new disk with all the data rebuilt from the old Data-disk now was mountable again and it seems, that the system runs without faults... However what concerns me is, that I now have a folder of 360GB on this newly installed disk (lost & found) as well as a new Share with the same name. This is to me really a waste of HD-space. It was not my intention to install a bigger data-disk just to waste the more space with a file, which I don't want... It is annoying to have a share 'lost & found', which I don't want, but which is bigger than most other folders... Can I delete it ? Or at least delete all content of it ? Should I install the old disk again and go to the total disk change procedure once again to get rid of that large lost & found folder ? I really do not want the lost & found folder occupy most of the additional space of my new hard disk - the exchange of data disk would be useless then. What is the experts advice ?

Ich habe heute nach dem Hardware upgrade (neue Parity disk und eine der Data-disks erneuert) nochmal probiert ob ich eine der Lacie externen USB platten nutzen kann fuer Backups mit dem rsync script... Leider negativ, wie schon eher berichtet ! Die 1Tb Lacie USB ist zwar schliesslich doch mit XFS formatierbar gewesen, aber das Backup wurde so nach 2-3Gb abgebrochen. Syslog: (sdb ist die USB platte) Was soll ich hiermit jetzt machen - bisher hat jede USB Disk aufgegeben nach ein paar GB schreiben... Aug 16 21:00:24 Tower emhttpd: cmd: /usr/local/emhttp/plugins/user.scripts/showLog.php MGutt_Fotos naar Backup_schijf 20 Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 00 58 76 25 88 00 00 f0 00 Aug 16 21:00:49 Tower kernel: blk_update_request: I/O error, dev sdb, sector 1484137864 op 0x1:(WRITE) flags 0x104000 phys_seg 8 prio class 0 Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 00 58 76 26 78 00 00 f0 00 Aug 16 21:00:49 Tower kernel: blk_update_request: I/O error, dev sdb, sector 1484138104 op 0x1:(WRITE) flags 0x104000 phys_seg 8 prio class 0 Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 00 58 76 27 68 00 00 f0 00 Aug 16 21:00:49 Tower kernel: blk_update_request: I/O error, dev sdb, sector 1484138344 op 0x1:(WRITE) flags 0x104000 phys_seg 8 prio class 0 Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 00 58 76 28 58 00 00 f0 00 Aug 16 21:00:49 Tower kernel: blk_update_request: I/O error, dev sdb, sector 1484138584 op 0x1:(WRITE) flags 0x104000 phys_seg 9 prio class 0 Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 00 58 76 29 48 00 00 f0 00 Aug 16 21:00:49 Tower kernel: blk_update_request: I/O error, dev sdb, sector 1484138824 op 0x1:(WRITE) flags 0x104000 phys_seg 8 prio class 0 Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 00 58 76 2a 38 00 00 f0 00 Aug 16 21:00:49 Tower kernel: blk_update_request: I/O error, dev sdb, sector 1484139064 op 0x1:(WRITE) flags 0x104000 phys_seg 10 prio class 0 Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 00 58 76 2b 28 00 00 f0 00 Aug 16 21:00:49 Tower kernel: blk_update_request: I/O error, dev sdb, sector 1484139304 op 0x1:(WRITE) flags 0x104000 phys_seg 8 prio class 0 Aug 16 21:00:50 Tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s Aug 16 21:00:50 Tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 00 58 76 2c 18 00 00 f0 00 Aug 16 21:00:50 Tower kernel: blk_update_request: I/O error, dev sdb, sector 1484139544 op 0x1:(WRITE) flags 0x104000 phys_seg 9 prio class 0 Aug 16 21:00:50 Tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s Aug 16 21:00:50 Tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 00 58 76 2d 08 00 00 f0 00 Aug 16 21:00:50 Tower kernel: blk_update_request: I/O error, dev sdb, sector 1484139784 op 0x1:(WRITE) flags 0x104000 phys_seg 8 prio class 0 Aug 16 21:00:50 Tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s Aug 16 21:00:50 Tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 00 58 76 2d f8 00 00 f0 00 Aug 16 21:00:50 Tower kernel: blk_update_request: I/O error, dev sdb, sector 1484140024 op 0x1:(WRITE) flags 0x104000 phys_seg 21 prio class 0 Aug 16 21:00:52 Tower kernel: sdb1: writeback error on inode 1628217011, offset 167772160, sector 1484121944 Aug 16 21:00:52 Tower kernel: XFS (sdb1): log I/O error -5 Aug 16 21:00:52 Tower kernel: XFS (sdb1): xfs_do_force_shutdown(0x2) called from line 1196 of file fs/xfs/xfs_log.c. Return address = 00000000fe4bac91 Aug 16 21:00:52 Tower kernel: XFS (sdb1): Log I/O Error Detected. Shutting down filesystem Aug 16 21:00:52 Tower kernel: XFS (sdb1): Please unmount the filesystem and rectify the problem(s) Aug 16 21:00:52 Tower kernel: XFS (sdb1): log I/O error -5 Aug 16 21:00:52 Tower kernel: XFS (sdb1): log I/O error -5 Aug 16 21:00:52 Tower kernel: XFS (sdb1): log I/O error -5

Hello - I want to follow this concept, but from an Ubuntu client (instead of Windows) However how do I do this ? Create additional user... should be ok created additional samba-user - should be also ok However finally I cannot mount the ubuntu ext4 disk in unassigned devices plug in It says permission denied - does it NEED write access ? Because when I grant full write access there is no problem....

Telefons sind für später - erstmal an den Rechner vom Gebraucher anschliessen und z.B. Fotos auf den PC spielen - das wird dann in den Folder gelegt, der einmal täglich mit rsync auf Unraid aufgespielt wird... Ich muss erstmal mit den einfachsten Dingen vertraut werden und klarkommen - wenn das richtig implementiert ist und ich auch verstanden habe warum und wieso, kann ich daran denken Dinge eleganter zu lösen... alter Mann kein D-zug...lol Danke für die Beispiele - das schaue ich mir an und probier es aus...

Hallo Joerg, ja, natürlich ist der Server ur-alt... aber wie gesagt, momentan beschäftigt mit unclear und leergeräumtem Array... wenn die neue Parity Seagate Exos und Data disk drin sind, kann ich wieder hochfahren und die USB Lacie Platten nochmal untersuchen... Marc, kann man das Syslog von gestern doch irgendwo sehen, wenn man letzte Nacht den Server ausgeschaltet hat ? Ich dachte das Log wäre weg, bei reboot... Wird wohl morgen werden, denn muss ja auch noch formatieren und das Array rebuilden - erst Parity (mit der alten Data-disk) dann die Datadisk wechseln, wenn ich das im Unraid Wiki richtig verstanden habe...

So - leider konnte ich mich nicht mit neuen Erkenntnissen melden, da der Unraid Server z.Zt. wegen der HDD-Wechsel runtergefahren ist. Vielen Dank für die vielen Hinweise. Ja, ich habe eben zunächst einfach die USB Platte in den USB-Stecker vom Unraid Server gesteckt (die Platte hat ein eigenes Steckernetzteil) und mit dem Unraid unassigned Disk Plug-in einen pre-clear ausgeführt... (es muss doch der destuctive Mode eingeschaltet gewesen sein, sonst hätte das doch gar nicht geklappt ?!?) Ich kann jetzt nicht nachschauen, aber soviel ich weiss, schmiss das Syslog vor allem I/O Errors raus und als dass dann nicht aufhörte ist nach ein paar Versuchen die Platte eben mit Error gestoppt. Dann habe ich erstmal alle Kabel gecheckt... auch Sata-kabel intern usw... teilweise ausgewechselt... Habe sogar im BIOS eine Funktion eingeschaltet womit (nach Angabe von Supermicro) der Takt des Servers so beeinflusst wird, das weniger EMC Probleme entstehen... Gestern habe ich alles mit einer zweiten Platte versucht - schliesslich ist es mit gelungen eine XFS Formatierung zu machen (also pre-clear und dann XFS formatiert) Danach einen Foto-Folder mit rsync script versucht zu kopieren/backup zu machen... Nach 10000 Fotos war schluss und Backup gecrashed.... wieder wegen I/O Fehlern.... Ich kann den Computer doch nicht in Schrauben, Muttern und Unterlegscheiben zerlegen um herauszufinden welche Leitung verstopft ist... Jedenfalls sind die Platten höllisch lahm (Intern Hitachi) Beim pre-clearen war am Anfang mit ca 25-30MB/s noch Hoffnung... aber gegen Ende ging das dann deftig runter.... Die Seagate Exos 12TB ist beim Pre clearen bei 30% noch mit 240MB/s unterwegs... Kann es sein, dass die Platten einfach zu langsam sind ? Ich werde auch mal versuchen, den USB controller im BIOS aus dem Legacy mode zu entlassen - dann kann der nur USB 2 und nicht mehr den alten Mode 1 - der Server ist ja schon sehr alt.... und damals... kann mich gar nicht mehr erinnern.....lol Syslog von gestern habe ich aber leider nicht mehr, da der Server heute Nacht ausgeschaltet war - heufe früh kam der Postbote mit den neuen Platten und da hab ich die USB-Dinger erstmal an die Seite gestellt, damit ich so schnell wie möglich das Array wieder starten kann. Der Server hat nur 4 HD-slots - wenn ich 2 platten wechseln will und erst pre-clear machen will muss ich zwangsläufig das Array stoppen.... bis neue Parity und Datadisk 'verdaut' sind... dann kann ich mich den USB Platten wieder zuwenden. Dann melde ich mich mit neuen Einzelheiten... Heute morgen nur mal eben getestet, was mein Ubuntu PC zu der XFS Platte sagt, die gestern die Foto-Backups abgebrochen hat.... XFS Filesystem prima in Ordnung ! Es ist also irgendein Ubertragungsproblem, was Arger macht. Hat aber wohl mit der Hardware im Unraid server zu tun.... nur ist da wirklich nix besonderes drin - Der USB port ist direkt auf dem Board, und trotzdem IO Errors...

Ich möchte gerne lernen, wie ich mein Home-Netzwerk einrichten muss, um so sicher wie möglich Backups machen zu können. Volgendes habe ich mir ausgedacht (Vorsicht Anfänger!): Im Haushalt gibt es verschiedenste Netzwerkteilnehmer: - windows PCs - Android Telefone - Linux PC - IoT devices (auf Linux Basis) Ich möchte nun realisieren, dass der Unraid server ausschliesslich benutzt werden kann zu: - Files lesen - Files vom Client zur Archivierung im Unraid Array auslagern (Backup von Daten von den Clients, Android telefon (z.B. Fotos von unterwegs), Linux PC) - Backup der wichtigsten Unraid Daten (application files und anderes) auf einem der Linux PCs als zweite Kopie. Habe dort Festplatten, die ich im laufenden Betrieb rausziehen kann und wegpacken (Supermicro SC-743TQ-B Workstation) - eine bessere Alternative als die externen USBs, die nicht nur langsam sind sondern auch viel Probleme bereiten (dazu demnächst in einem anderen Thread) Die Idee von der Netzwerk Konfiguration ist, das alle Clients immer Ihre Daten zunächst für sich behalten, bis diese nur 1x täglich von Unraid zur Archivierung abgeholt werden (ohne Schreibrechte auf dem Client PC) . Zusätzlich sollen mit dem rSync script von MGutt auch regelmässig Sicherungskopien von Unraid gemacht werden und zwar auf Anfrage von dem Supermicro Linux-Client. Der Linux Client liest dann die Daten mit "nur Leserechte" vom Unraid runter, ohne das irgendwelche Manipulationen op dem Unraid Server möglich sind. Dadurch daß auf dem ganzen Netzwerk niemand Schreibrechte auf einem anderen PC hat als auf seiner eigenen Festplatte, wäre das ein halbwegs wasserdichtes System.... wenn man Ausnahmen vermeiden kann. Soweit die Idee... Macht das Sinn ?! Das Problem ist nur leider, daß ich auch mit viel Lesen im Internet (und verbliebenem Gehirnschmalz) keinen blassen Schimmer habe, wie man das konkret realisiert! Nehmen wir den Linux PC als konkretes Beispiel: Wie erreiche ich, das Unraid mit Leserechten zur Archivierung vom Linux-PC Daten einlesen kann (sicherungskopie Client im Unraid Array) Und umgekehrt wie erreiche ich, das der Linux-PC nur mit Leserechten vom Unraid Server bestimmte Folder mit dem rsync Script vom MGutt abliest und auf einer grossen HDD als Unraid Backup ablegen kann ? Was muss ich in Samba einstellen, damit das System wie oben geschildert wasserdicht ist und bleibt... Wenn ich das für dieses Beispiel mal verstanden habe, gelingt es mir wohl hoffentlich auch von den Windows PCs und schliesslich auch von den Android telefonen ? Man koennte Daten von den phones auch erstmal in einen PC folder laden und dann am Abend oder Nachts vom Unraid abholen lassen zur Archivierung. Ansonsten verbringe ich jetzt die Zeit mit Samba Büchern.... lol... leider verstehe ich nur wenig davon.

HDDs sind geliefert und schreiben Nullen mit pre-clear im unassigned disk plug-in Wettrennen: Seagate X16 12TB gegen Western Digital Red pro 4TB Beide HDDs sind trotz meines uralt-Systems mit nur 4GB Ram erstaunlich schnell - Seagate bei 240MB/s, Western Digital bei 225MB/s nach ca 30%... Jetzt ist es erstmal abwarten und Tee trinken....

Für erste Backup's mit MGutt's scripts würde ich gerne vorhandene externe Lacie USB-1TB Platten verwenden. Auf dem PC habe ich die Platten leer gemacht. Nach vielen Stunden pre-clear wollen die Platten aber nicht akzeptieren, das die neue Partition in XFS formatiert werden soll... Ich bekommen immer FAIL... Ich habe das ganze dann anstatt mit dem Unassigned Plug-in im Server dann auf meinem Ubuntu Rechner versucht . Auch hier gab der Versuch die Partition mit XFS zu beschreiben sofort Abbruch. Was ist hier die Ursache und gibt es Abhilfe ? NTFS führt leider bei dem MGutt-Backup-Script (Vers 0.6) zu Problemen, weswegen ich gerne ein native Unraid File-system verwenden wollte. Das NTFS Filesystem macht keine Incremental Backups, sondern schreibt alles wieder "in voller Länge" nochmal.... das will ich vermeiden... Aber XFS Formatierung funzt nicht. Ist die Bedingung möglicherweise, daß man die Partition nicht (bei einer 1TB platte) 1TB machen darf sondern einen mehr oder weniger grossen "Rest" lassen muss.... sagen wir 3GB... leer lassen ? Ich habe nämlich 1 Partition von der Grösse der ganzen Platte gewählt... Habe die Platten vorab zig Stunden pre-clear machen lassen.... hilft nicht. Mit NTFS arbeiten die Platten allerdings gut... nur hilft mir das nicht weiter als Backup Lösung. Hat jemand ein "Spezialtool" wie ich den Platten Ihre Microsoft NTFS "Süchtigkeit" austreiben kannen - sozusagen einen Software - "Ausklopfer"???? Danke P.S.: vielleicht ist da von Lacie irgendwas drauf, was das Formatieren in anderem Format als NTFS verhindert ? Das war auch ein Grund, warum ich erstmal davor zurückschreckte solche externen Platten auszuschlachten für die interne Verwendung im Server...

Ja genau - die Platte habe ich vorgesehen als Parity in der 12TB Variante Die wird bei uns inzwischen unter 300 Euro angeboten (incl. 21% MwSt) Es wird eben besonders auch bei der Parity Disk wichtig, dass die nicht in den nächsten 5 Jahren "den Verkehr aufhält" Aber wie gesagt eben nicht sooooo kritisch bei mir. Und die WDpro's sind offenbar alle auch CMRs...

Ich brauche sehr dringend Ersatz und habe deshalb heute eine Bestellung gemacht. Meine vollste Data-disk macht jeden Tag exponentiell mehr Write Errors und ich habe den Server deswegen heute schon ausgeschaltet, da ich nicht möchte das die Platte vor dem Wechsel bereits ausfällt. Die 1TB platte wechsele ich gegen eine Exos 12Tb (habe im Internet nix gefunden zu SMR für den Typ. Die kaputte 1TB Data Platte wechsele ich in eine 4TB WD red pro - sind die Pro denn auch SMR ? Habe dazu nix gefunden - offenbar aber so gut wie alle nicht pro- Reds Ansonsten habe ich mal wieder Anfänger-Pech und die Auswahl war hier auch nicht so riesengross... Es sind ubrigens keine externen Platten. sondern Hardware fuer den direkten Einbau Der Preis Unterschied ist weniger als 10% und der Nachkauf war eher dringende Reperatur als normales Upgrade. Ich werde dann mal schauen ob es irgendwann grosse externe irgendwo im Angebot gibt, wo sich das Ausschlachten wirklich lohnt - man muss ja auch bedenken, daß die Garantie erlischt und als Newcomer... Ich muss dazu sagen, dass ich praktisch kaum zeitkritische App's habe (Kein Video-Mediaserver, sondern Fileserver und ein ganz kleines bisschen Datenbank - paperless ng und Calibri eben) - Mit Video oder gar Spielen, etc wäre hier ja lange Sabbat mit dem Supermicro von 2008... Erstmal Erfahrungen sammeln und dann mit mehr Sachverstand später (wenn wieder Budget ist) was richtiges.... aber wir älteren Herrschaften sind nicht so die Gamers... Ich habe übrigens einige Tests gemacht mit Deinem Backup script... dazu werde ich aber im Englischen Teil im 'incremental Backup" Post noch was schreiben... Danke für die Antworten...