Beiträge von linuxnutzer


    Ja, der richtige Pfad zu externen Laufwerken ist ist immer so was wie /share/external/sdy5/. Den kannst Du natürlich auch nehmen.
    Die Syntax von rsync ist immer: rsync [Optionen] <VON> <NACH>, d.h. bei Dir dann wahrscheinlich
    rsync -av --stats --progress /share/Public/ /share/external/sdy5/Public


    Linuxnutzer

    Ok, da Du Dich ja mit der Kommandozeile auskennst, kannst Du ja mal einen Test durchführen. Ich weis nicht genau, welche Parameter von Qnap für rsync zum Synchronisieren verwendet werden, normalerweise benutze ich den Archiv-Modus (-a). Du startest rsync einfach mal von der Kommandozeile und schaust, ob und wo es einen Abbruch gibt. Ich nehme an, Deine externe Festplatte ist USBDisk1.


    Code
    1) Testverzeichnis auf der USB-Festplatte anlegen:
    mkdir /share/USBDisk1/Testverzeichnis
    
    
    2) rsync aufrufen mit einem von Dir gewünschten Quellverzeichnis (z.B. Qmultimedia):
    rsync -av --stats --progress /share/Qmultimedia /share/USBDisk1/Testverzeichnis
    
    
    3) Wiederhole 2) für alle Quellverzeichnisse.


    Ich hoffe, ich hatte alles richtig im Kopf, da ich im Moment nicht auf mein NAS schauen kann.


    Linuxnutzer

    Hi,


    vielleicht hast Du Glück und es ist kein Hardware/Kernel/Treiber-Problem. Jedenfalls gibt es keine entsprechende Meldung vom Kernel, wie ich der dmesg-Ausgabe entnehmen kann.
    Was hast Du denn für Backup-Optionen eingestellt? Sync oder Copy?
    Was für ein Filesystem hat die externe Platte?
    Welche Firmware ist auf dem NAS? Im letzten Firmware-Changelog für die TS-110/119/210/219/410/419 stand:
    "Synchronization option is temporarily replaced by cp command because of the current known limitation of selected file size. The fix will be available in the next release."
    D.h. es gibt wohl ein Problem mit rsync in vorherigen Versionen. Hast Du große Dateien? Größer als 2GByte im Backup?


    Linuxnutzer

    Hi jekie,


    Deine dmesg-Ausgabe sieht erst mal unverdächtig aus. Hast Du dmesg wirklich gleich nach einem Abbruch ausgeführt? Sieht eigentlich aus wie frisch nach dem Booten.


    Zum USB-Problem gabe es auch mal ein Thema: http://forum.qnapclub.de/viewtopic.php?f=27&t=4114.


    Ich vermute immer noch ein Hardware/Treiber-Problem. Ich selbst benutze eine externe USB-Festplatte zum Backup mit rsnapshot. Beim Sichern von sehr großen Datenmengen kommt es hin und wieder zum Abbruch. Daher betreibe ich rsnapshot im "Sync-Modus". Nach einem Abbruch rufe ich "rsnapshot sync" so lange auf bis alles kopiert ist. Auch beim täglichen Backup wird so sichergestellt, daß keine unvollständige oder defekte Sicherungen entstehen.


    Linuxnutzer

    Hi,


    habe mal an Snake ne Anleitung für dovecot geschrieben, weis aber nicht, ob er es letztendlich hinbekommen hat.


    -----------------------------------------------------------------


    Da mir xdove ein wenig zu "fett" schien, habe ich dovecot als ipkg per Hand installiert. Ich benutze dovecot nur als Mail-Archiv. Ich habe hier daheim einige Rechner und die Mails lagen immer auf dem falschen rum. Ein Synchronisieren der Mailfolder ist nicht sinnvoll, da ich auch mit verschiedenen Mailclients zugreife. Aber der dovecot läßt sich überall als Mailaccount einrichten und von jedem Mailclient können Mails dorthin verschoben werden. Außerdem kann man die Mailfolder ins tägliche Backup einbeziehen, vollautomatisch mit rsnapshot, womit man sehr leicht gelöschte Mails wiederherstellen kann.
    Drei Hürden galt es zu überwinden:


    1) dovecot wurde nicht automatisch gestartet. Das mit der autorun.sh klappte nicht, da zu dem Zeitpunkt anscheinend die Optware noch nicht initialisiert ist. Also hab ich mir die /opt/Optware.sh geschnappt und "/opt/etc/init.d/S90dovecot start" als letztes in die start) section und "/etc/init.d/S90dovecot stop" als erstes in die Stop) section eingetragen.


    2) In der /etc/config/passwd sind die Home-Verzeichnisse der User nicht eingetragen. Das muß man von Hand machen, da sonst der dovecot sie nicht findet. Die Zeile für User mustermann müßte dann so ähnlich aussehen.


    Code
    mustermann:x:500:100:Linux User,,,:/share/mustermann:/bin/sh


    Das Homeverzeichnis wird zwischen den letzten beiden Doppelpunkten eingetragen.


    3) Die dovecot-Konfiguration mußte ich noch per Hand anpassen, um ein Login der NAS-User zu ermöglichen. Man kann dovecot auch so einrichten, daß kein Useraccount auf dem NAS vorhanden sein muß, aber damit habe ich mich nicht beschäftigt. Desweiteren habe ich keinen ssl/tls-Zugriff eingerichtet, da ich nur aus dem Heimnetz zugreife.
    In der /opt/etc/dovecot/dovecot.conf habe ich den Abschnitt:


    Code
    passdb shadow-file {# File contains a list of usernames, one per lineargs = /etc/passwd#args = /etc/dovecot.deny#deny = yes}


    nach


    Code
    passdb shadow {# File contains a list of usernames, one per line#args = /etc/passwd#args = /etc/dovecot.deny#deny = yes}


    geändert und die Mailverzeichnisse folgendermaßen konfiguriert:

    Code
    mail_location = maildir:~/.Maildir


    Die Mails liegen also im Home-Verzeichnis der NAS-User in einem versteckten Ordner. Die User können sich also mit ihrem NAS-Login zu dem IMAP-Server mit ihrem Mailprogramm verbinden. Die Wahl von maildir als Mailboxformat hat zwei entscheidende Vorteile gegenüber dem default mbox.
    a) Mailboxfolder können Folder und Mails gleichzeitig enthalten.
    b) Beim Backup müssen nur die neuen Mailfiles kopiert werden und nicht das ganze geänderte (evtl. sehr große) mbox-file.


    Alles klingt vielleicht kompliziert, aber man macht das nur einmal und dann läuft es für immer


    Viel Spaß


    Linuxnutzer

    Zitat von "Complicated"

    :-/
    Dann entspricht der Tipp mit dem Verzeichnis also ungefähr dem mit einem Edding auf Backplatten einen grünen Punkt zu machen.
    Das interne sichern verhindert also die Einstellung in rsnapshot.conf

    Code
    no_create_root 1


    und nicht das Backup-Verzeichnis wie hier geschrieben:


    Ja, in dem Fall schon. Nur es gibt auch Systeme (UNIX allgemein), daß der Mountpunkt (z.B /mnt/usb1/) immer existiert und ein Verzeichnis auf der Root-Partition darstellt. Wenn ein externes Laufwerk unter /mnt/usb1 eingehangen wird, dann "überdeckt" es sozusagen die Root-Partition ab dieser Stelle. D.h. geschrieben werden kann immer nach /mnt/usb1/, aber wo die Daten landen hängt davon ab, ob das externe Laufwerk gesteckt ist oder nicht, rsnapshot allein hat da keine Info. Die Idee war halt, daß rsnapshot über die Existenz eine bestimmten Verzeichnisses auf der externen Platte (/Backup) doch eine Info bekommt, daß die Backup-Platte steckt und ein Sichern in die Root-Partition verhindert wird.


    Linuxnutzer

    Zitat von "Complicated"

    Ja aber leider kann man das nur auf der Konsole und nicht in der Adminoberfläche angeben :mrgreen:
    Dort musst du mit den Angebotenen Symlinks im Dropdown arbeiten.


    Ok, ich bin eigentlich immer auf der Konsole unterwegs mit dem Midnight-Commander (mc).


    Linuxnutzer


    Also, ich denke schon, daß rsnapshot auch verschachtelte Verzeichnisstrukturen anlegen kann. Nur die Option no_create_root 1 hindert es daran. Dann macht rsnapshot gar nichts, wenn das unter snapshot_root angegebene Verzeichnis nicht gefunden wird.
    Das Verzeichnis /Backup auf der externen Platte dient nur dazu, mehrere externe Platten unterscheiden zu können. Auf Platten mit /Backup wird gesichert, auf alle anderen nicht.


    Linuxnutzer

    Hi,


    USBDisk1, USBDisk2 etc. sind nur Symlinks auf die wirklichen Verzeichnisse. Diese liegen bei mir (TS119) unter /share/external/. und scheinen nach USB-Anschluß immer gleich vergeben zu werden. So hat bei mir der rechte hintere Anschluß immer /share/external/sdt1 (1 für die erste Partition), egal ob die Platte den Symlink USBDisk1 oder USBDisk2 bekommt. Ich gebe als in der Backupkonfiguration immer /share/external/sdt1 an.


    Linuxnutzer

    Hi Complicated,


    habe mich vielleicht etwas mißverständlich ausgedrückt. Mit
    snapshot_root /share/eSATADisk1/Backup
    wird das Verzeichnis angegeben, unter dem alle snapshots inclusive Verzeichnishierarchie angelegt werden. D.h. mit
    Backup /share/MD0_DATA/Public Server/Public
    gibt es dann
    /share/eSATADisk1/Backup/daily.0/Server/Public/...
    Wenn
    no_create_root 0
    gesetzt ist, dann wird u.U. das Verzeichnis /share/eSATADisk1/Backup erst angelegt, wenn z.B. die Platte abgesteckt ist. /share ist ja ein Verzeichnis im root-Filesystem, von dem ich jetzt nicht genau weis, welche Partition dahintersteckt. Auf alle Fälle ist ein Backup dorthin nicht ratsam.
    Nur mit angesteckter Platte zeigt der vom System angelegte Symlink /share/eSATADisk1 auf die externe Platte.
    Ein Verzeichnis Backup oder ähnlich verhindert, daß auf eine andere externe Platte gesichert wird, was ja passieren kann, wenn stündliche Backups konfiguriert sind, aber gerade eine andere Platte angesteckt ist zwecks Datenaustausch, die dann ja auch unter /share/eSATADisk1 eingehangen wird und natürlich kein Verzeichnis /Backup enthalten sollte.


    Linuxnutzer

    Zitat von "Complicated"

    Ich habe bei mir für die eSATA´eingetragen:

    Code
    snapshot_root /share/eSATADisk1/


    Ich würde mal darüber nachdenken, die Option
    no_create_root 1
    zu verwenden und nicht direkt nach /share/eSATADisk1/ zu sichern, sondern z.B. nach /share/eSATADisk1/Backup. D.h. auf der externen Platte muß zuvor ein Verzeichnis Backup angelegt werden. Damit erreicht man, daß rsnapshot nicht ausgeführt wird, wenn es /share/eSATADisk1/Backup nicht findet, was ja passieren kann, wenn die Platte abgesteckt ist oder eine andere Platte dranhängt. Im ersteren Fall würde rsnapshot nämlich trotzdem nach /share/eSATADisk1/ sichern, nur liegt dieses Verzeichnis nun auf der/den internen Platte(n), da rsnapshot /share/eSATADisk1/ neu anlegt, falls der Symlink eSATADisk1 nicht existiert. Da kann dann ganz schnell das NAS überlaufen:)


    Linuxnutzer

    Hi Viper666,


    bei meiner TS119 ist das mit dem USB auch ein wenig wackelig. Ich habe letzte Woche eine neue Backup-USB-Platte angeschlossen und brauchte auch mehrere Anläufe bis rsnapshot das erste Backup kopiert hatte (ca. 350 GByte). Zwischendurch war die Platte ein paar mal weg. Bei den inkrementellen Backups hatte ich aber seit einem halben Jahr nie Probleme, da dort höchstens ein paar GByte übertragen werden. Ich vermute auch so was wie einen "thermischen Hardwarefehler". Ich werde das Gerät auch nicht in den Service bringen, da ich nicht daran glaube, daß sich dort jemand die Mühe macht diesen selten auftretenden Fehler zu verifizieren. Über mein Fotoarchiv hab ich md5-Summen berechnet und weis daher, daß alles in Ordnung ist und kein Bit falsch übertragen wurde.


    Linuxnutzer

    Hi,


    es geht auch ohne die autorun.sh zu benutzen.


    1) Midnightcommander über ein shell-script /opt/bin/mcc aufrufen. Darin steht einfach "mc -c $@".
    2) Einstellungen des mc in das globale Konfigurationsverzeichnis des Midnightcommander /opt/share/mc/ speichern, d.h. /root/.mc/ini nach
    /opt/share/mc/mc.ini kopieren. Dort bleibt sie auch nach einem Reboot erhalten. Natürlich sollte man vorher alle Einstellungen machen und speichern :)


    Linuxnutzer

    Hi,


    also ich sichere meine Rechner mit rsync vom Rechner zum NAS, da der NAS ja nicht wissen kann, wann und wie lange der Rechner an ist. Das mache ich als root. Um eine Passworteingabe (zum Zugriff auf das NAS) zu vermeiden, kann man SSL-Zertifikate austauschen, so daß root sich ohne Passwort mit rsync zum NAS verbinden kann. Damit könnte rsync dann auch als cron oder anacron job laufen, ohne daß ein user das root oder das NAS-Admin Passwort kennen muß.
    Ich synchronisiere vom Rechner zum NAS eine Auswahl von Verzeichnissen in ein Verzeichnis auf dem NAS, z.B nach /share/HDA_DATA/LinuxRechnerBackup. Bei mehreren Rechnern könnte man noch den Hostname verwenden im rsync script, z.B. /share/HDA_DATA/LinuxRechnerBackup/`hostname`. Damit ist auf dem NAS immer der aktuelle Stand und es werden pro Sync immer nur die Unterschiede übertragen. Die eigentlichen Backups lasse ich vom NAS durchführen (automatisch per cron). Dafür verwende ich rsnapshot, welches das Verzeichnis /share/HDA_DATA/LinuxRechnerBackup nochmals auf eine externe Platte sichert und dabei eine Historie aller Files anlegt, d.h. man kann auch ein z.B. vorgestern gelöschtes File wiederherstellen.


    Linuxnutzer

    Hi dmark,


    freut mich, daß es geklappt hat. Ich habe damit auch mal experimentiert. Ich finde es schade, daß Qnap es nicht erlaubt, den Copy-Knopf selbst zu belegen. Es ist alles fest verdrahtet in einem Binary. Ich habe mir ja gerade Qnap gekauft, um eigene Sachen zu machen, an die die Entwickler nicht alle denken können. Insofern hätte man wenigstens einen Scriptaufruf einbauen können, dessen erste hundert Zeilen einen Kommentar enthalten, der jegliche Supportansprüche ausschließt, wenn man selbst was ändert:)


    Linuxnutzer

    Hi


    ein Hinweis für alle, die rsnapshot benutzen (Version 1.3.1). Aus der FAQ:


    Q: I have a snapshot root or backup point with a space (or other special character) in it and this is not working at all with rsnapshot 1.3.1. Why?
    A: rsnapshot version 1.3.1 has an issue where the rsync command is interpreted by a shell rather than directly executed by rsnapshot. This bug is expected to be fixed in rsnapshot CVS on 24 March 2009, and so should appear an a forth-coming release (probably version 1.3.2). This bug was not present in rsnapshot 1.3.0.


    Linuxnutzer