ullibelgie

Members
  • Posts

    69
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

ullibelgie's Achievements

Rookie

Rookie (2/14)

3

Reputation

  1. Danke für die Hinweise - werde mich dann damit auch mal genauer beschäftigen ... vielleicht ist das eine gute Lösung für mich - die Tatsache, daß man das auch von ausserhalb Unraid ausführen kann mit nur Leserechten auf dem Unraid server ist jedenfalls sehr positiv Um Clients auf Unraid zu sichern, könnte ich dann wiederum den luckybackup docker auf Unraid installieren um mit nur Leserechten von den Clients auf einen Backupshare von unraid zu schreiben... So wird immer das Backup ausgeführt dort wo es auch geschrieben wird... Luckybackup gibt es sogar für Windows sehe ich gerade.... aber das brauche ich nicht.... Mal schauen...
  2. Das weiss ich nicht mehr genau ... aber man kann ja wirklich nicht viel falsch machen eine Zeile in die [Global] section zu schreiben. Das ist ja Monate her und der Computer seitdem jeden Tag Abends ausgeschaltet und morgens wieder an... Wenn es nur mit SMB 1 funktionieren würde, wäre das nicht gut... scheinbar wird da noch gewerkelt um das auch mit den letzten Releases von Samba zum laufen zu bringen... Ich werd mal versuchen mit NFS zu mounten... In der Zwischenzeit geht für mich dann wohl nur die schnelle Lösung mit luckybackup bis deutlich ist, was man beim lokalen Ausführen des Scripts alles ändern muss - leider geht das über meine "Fähigkeiten".... oder eben über meinen laienhaften Gebrauch...
  3. Das habe ich inzwischen auch gesehen. Ich hatte aber gehofft, daß ich mit dem Gebrauch von dem Bash Script von MGutt eben mehr lerne als nur Knöppe zu drücken. Womöglich mit der Folge, dass wenn ich wirklich mal einen restore machen muss die Software auch nicht richtig benutzt habe... naja - vielleicht bin ich ja doch zu dumm, das Bash script zu verstehen - dann wird es lucky backup werdem müssen. Unterschiede sind wohl vor allem darin zu suchen, wenn man bestimmte alte Backups aufbewahren will - dann muss man das mit luckyBackup eben manuell machen... habe mich aber damit noch nicht so beschäftigt. Jedenfalls Danke für den Hinweis - ist dann mein Rettungsanker, wenn es nix wird mit MGutts Script...
  4. Ich kann doch am Ubuntu Rechner nicht mehr tun als in smb.conf unter [global] eintragen unix extensions = yes Ich habe nachgesehen - auch in Unraid ist im SMB setting eingetragen: unix extensions = yes Wenn das nicht korrekt ist: wie muss es dann richtig gemacht werden ? Und: Muss im smb.conf der Eintrag an einer ganz bestimmten Stelle gemacht werden, weil das ansonsten nicht funktioniert ?! Das Script auf dem Ubuntu Rechner funktioniert nicht, da die Verweisungspfade alle nicht mehr stimmen (z.B. der Notifikations) ausserdem bekam ich auch allerlei andere Fehlermeldungen - als quasi Laie was coding angeht, habe ich es dann mal gelassen...
  5. Um meine Verwirrung komplett zu machen: Mein Testfile bei der Ausführung von ln vom Unraid-terminal war 650kB gross Frage: wie gross ist also Testfile und Linkfile (der vermeintliche Hardlink von Testfile) dann zusammen ?? Ausführung im Unraid Terminal mit cd im Zielverzeichnis stehend: du -d1 -h liefert 1.3MB (also kein Hardlink ?!?) Ausführung direkt auf dem Zielrechner im Terminal des zielverzeichnisses: du -d1 -h liefert 650kB (also doch Hardlink ??) Wat denn nu ?!
  6. Ich kann nur als Anfänger der simpelen Logik folgen - für alles andere im Internet die Syntax suchen... also weitermachen: Ich hatte auf dem Ubuntu Rechner (Ziel für das Backup von Unraid was ich machen möchte) ja festgestellt, daß hardlinks funktionieren, wenn ich lokal mit Befehl 'ln' links setze. Nun ist aber die Frage, was passiert wenn ich das Zielverzeichnis von dem Backup-PC in Unraid mounte (unassigned devices plug-in) und dann im Terminal von Unraid die gleiche Procedure mache wie oben beschrieben - einziger Unterschied ist dann, dass der Befehl über SMB ausgeführt wird: Also im Terminal von Unraid eingeben: cd /mnt/remotes.... (Zielverzeichnis) Dann im Zielverzeichnis eingeben: ln testfile.pdf linkfile.pdf Kontrolle: ls Es ist jetzt nicht nur testfile.pdf im Ordner, sondern auch linkfile.pdf Jetzt checken nach Inode nummer: ls -i -h Die Inode nummern sind verschieden !! Das bedeutet doch, dass mit ln so keine Hardlinks geschrieben werden können über SMB von Unraid nach Ubuntu ! Was ist hier faul ? Oder ist das normal ? Es sieht hier so aus, als ob bei mir die Hardlinks erzeugen eben nur lokal geht aber nicht via SMB ! Doch irgendwas nicht richtig mit den Unix-extensions ? Wo muss ich was ändern in den Einstellungen ? Eigentlich wäre es das beste, das Script auf dem Zielrechner laufen zu lassen, wo auch geschrieben wird - aber dafür muss das Script neu geschrieben werden - das geht mit der Vorlage von MGutt leider gar nicht... Was tun ? Oder doch alles sein lassen und mit irgendeinem anderen Backuptool arbeiten ? Ich will aber was lernen und nicht nur Knöppe drücken...
  7. noch vergessen: ls -i und ls-l gibt natürlich die Anzahl der Links auch mit 2 an...
  8. So ich habe das jetzt mal gemacht: Ein File geschrieben auf den Zielrechner (Ubuntu) auf die gemountete Backup-HDD: 'testfile' (einfach ein paar Zeilen Text) Dann mit ln im Terminal einen Link, also im terminal eingegeben ln linkfile testfile" Es entsteht im Folder ein neues File 'linkfile' und ich habe jetzt also 2 files in dem Folder, nämlich testfile.txt und linkfile.txt Dann mit ls -i und ls -l festgestellt, das beide Files dieselbe Inode Nummer tragen, nämlich 11403266 Nochmals controlliert mit Eingabe im Terminal: find . -inum 11403266 Es wird ausgegeben: ./testfile ./linkfile Das beweist, das 'linkfile' auf dieselben Daten verweist wie 'testfile' - ich also mit ln einen hardlink schreiben kann auf meinem Ubuntu Rechner... Die Frage ist jetzt - wie gross ist der Folder "Link_Testen" in dem die beiden Files sind ! du -dl -h ergibt 16k Das ist weniger als 2x das Testfile, denn das testfile ist bereits 10k gross... Also kann Linkfile nur ein Hardlink sein (was zu beweisen war) Jetzt: Warum funktioniert das aber nicht mit dem Script ? Mir ist nicht klar, was mir die Testprocedure mit ln und ls Befehlen im Terminal auf dem Zielrechner bringen soll - ich weiss jetzt nur, das der Ubuntu Zielrechner Hardlinks kann.... Wie kann ich weiter vorgehen um das Script correkt zum laufen zu kriegen ? Danke!
  9. 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...
  10. 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.
  11. 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.
  12. "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
  13. 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
  14. 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...