YaST2 - Rear - Relax and Recover bitte um Hilfe

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

Hinweis: In dem Thema YaST2 - Rear - Relax and Recover bitte um Hilfe gibt es 10 Antworten auf 2 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • YaST2 - Rear - Relax and Recover bitte um Hilfe

    Moin Moin in die Runde.


    Ich habe an verschidenen Stellen hier im Forum davon gelesen, das sich mit ReaR eine Tragfähige Datensicherungs-Strategie aufbauen lässt.


    Also wende ich mich hier an die Spezialisten die diese Software kennen und anzuwenden wissen.
    Ich habe zwar versucht mich so gut es geht einzulesen, stelle jedoch fest, dass sich für OpenSuse
    keine für mich verwendbaren Anleitungen zu geben scheind.


    Der Stand der Dinge ist, das ich OpenSuse 15.0 mit KDE Plasma 5.1 benutze auf dem Desktop.


    Hier ist bald wieder ein DUP fällig und ich habe nicht wirklich das Verlangen nach der Aktualisierung
    mit einem Beschädigten System zu sein.


    Also bemühe ich mich um ein besseres Vorgehen.
    ReaR verspricht ja so einiges.


    Ich habe 2 Pakete, rear und YaST2-rear installiert und beim ersten Start im Yast kommen auch gleich die
    Meldungen was nicht geht!
    Keine Vfat Unterstützung. Wie kann das sein? Der Stand ist doch das die Boot-Partition mit gesichert werden muss.
    Und da ich gerade dabei bin, wie ist das mit den UIDs der Festplatten und Partitionen?


    Als erstes würde mir sehr helfen, welche Dateien von Rear ich wie bearbeiten muss um mein System und mein
    Home/benutzer zu sichern.
    Wie geht der Vorgang, dass ich die Daten zurückschreiben kann?


    Also frage ich Euch höflich nach ein wenig zielführender Anleitung und Aufklärung wie ich das Programm
    einsetzen kann.


    Freue mich sehr auf Antworten, Hinweise und Fragen beantworte ich gern


    Ahoi von hier aus

    Für den Inhalt des Beitrages 136892 haftet ausdrücklich der jeweilige Autor: leon_herford

  • leon_herford schrieb:

    Keine Vfat Unterstützung. Wie kann das sein? Der Stand ist doch das die Boot-Partition mit gesichert werden muss.
    Und da ich gerade dabei bin, wie ist das mit den UIDs der Festplatten und Partitionen?
    Dort nachfragen:
    GitHub - rear/rear: Relax-and-Recover - Linux bare metal disaster recovery and system migration solution (cfr. mksysb, ignite)
    Links in dieser Signatur bitte zum Lesen anklicken!

    Code-Tags <<<Klick mich
    zypper <<<Klick mich
    Netzwerkprobleme <<<Klick mich

    Für den Inhalt des Beitrages 136893 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Moin zusammen,

    hä? REAR unterstützt vfat doch????
    zudem sollte man sich REAR runterladen, installieren und das Ganze dann händisch!!!! konfigurieren.

    Die Anleitung ist mittlerweile auch vorhanden und ganz ok.
    Viele Grüße,
    T.

    Für den Inhalt des Beitrages 136911 haftet ausdrücklich der jeweilige Autor: Tamerlain

  • Erstmal Danke für die Antworten.


    @Sauerland
    Dein Link hat mir sicher Unterstützung gegeben, aber mit der Sprache habe ich es nicht so sehr. Habe
    die letzten Stunden mit Lesen verbracht, auch wenn ich nicht so viel davon verstanden habe.

    Ich konnte jedoch erreichen, das ich eine USB Sicherung wohl erreichen konnte.
    Erwartet hatte ich ein Datenvolumen von etwa 40Gb. Ist aber nur 8Gb groß.
    Ob sich daraus was sinnvolles wiederherstellen lässt?

    Was dabei tatsächlich >>Gesichert<< wurde, das kann ich auch kaum aus dem Log erkennen. Ist so
    um die 6000 Zeilen lang. Das aus meinem /home was gesichert wurde... ich finde die Zeichenkette nicht einmal mit Kate.


    @Tamerlain
    Du bist Schuld. :whistling:
    In einem lange zurück liegenden Satz haste davon mal geschrieben. Also von ReaR. Du hattest eine guten und Hilfreichen Gedanken.
    Keine gute Tat bleibt ungestraft. Nun haste den Salat.

    So im Allgemeinen möchte ich sda mit 3 prim. Pat. in einem Durchgang >>Sichern<<, so das ich von dem USB
    die Daten wieder herstellen kann.
    Der USB den ich mit ReaR erstellt habe, der lässt sich auch Booten und ein Menü ist auch zu sehen.

    Aber ich habe ja weiter gelesen und dabei ein
    rear dump
    abgeschickt und sicher einiges lesen können. Aber ob das angezeigte was mit opensuse lep 15 was
    gemein hat... Zumindest steht davon nichts treffendes geschrieben. Was ich da zu lesen bekomme ist mehr
    erschreckend als Hilfreich. Von suse 12 und i386 ist die Rede.

    Dabei ist mir aufgefallen das die Version schon recht alt (2017-12-20) ist.
    Kommt aus den Suse Repos.
    Ich hab da so einen verdacht ...... opesuse leap 15.0 kannte da wohl noch Niemand.

    Was ich bis jetzt begriffen habe ist:
    Das Yast modul scheint so nicht unbrauchbar.
    es müssen Einträge in die local.conf geschrieben werden. Habe ich nach der Anleitung USB gemacht.
    dann gibt es noch andere .conf die auch noch wichtig sind, sich mir aber nicht erschließen.
    Das erzeugte Datenvolumen scheint mir viel zu gering, als das diese Sicherung brauchbar sein könnte.
    ..............
    Das Programm soll doch nur alles von sda(1,2,3) auf seine Weise auf sdX kopieren. So das ich sdX aus dem
    Bios Starten und die Daten bei Bedarf auf sda, so wie gewesen, wiederherstellt.
    ..............
    Ist mit Sicherheit ganz simpel, ich steh nur grad im Wald und seh die Bäume nicht.
    ich begreife diese spezielle Syntax nicht. Kopieren kann ich die wohl, aber ich versteh nicht was ES
    bedeuten soll. Zu viel unbrauchbares Halbwissen.

    Anweisungen kann ich ausführen und Fragen beantworten. Englisch lesen und verstehen ist da nicht mein Ding.

    Hoffe das ich nicht zu viel Blödsinn geschrieben habe.


    ahoi von hier aus.

    Für den Inhalt des Beitrages 136926 haftet ausdrücklich der jeweilige Autor: leon_herford

  • Moin zusammen,

    REAR kann 2 Modi - Sicherung auf TSM und Sicherung auf NFS jeweils mit oder ohne Boot ISO.
    Wenn man mit Boot ISO arbeitet, wird in beiden Fällen eine kleine Boot ISO Datei erzeugt, die die Grundstruktur enthält und ausserdem die Zugangsdaten zum NFS oder TSM.

    Bei NFS wird im Prinzip eine riesige tar.gz Datei erzeugt, die das gesamte System enthält. Die ISO hat die Partitionen und all das.
    Man kann mit REAR auch schön das incremental backup durchziehen.
    Sprich einmal die Woche full backup und die restlichen Tage incremental.
    Viele Grüße,
    T.

    Für den Inhalt des Beitrages 136936 haftet ausdrücklich der jeweilige Autor: Tamerlain

  • Neu

    Hallo in die Runde

    @Sauerland
    @Tamerlain
    @Berichtigung

    Ich habe mich nun einige Tage und viele Stunden mit ReaR beschäftigt und habe Ergebnisse von denen ich
    hier nun berichten möchte.

    Das Restaurieren der Dateien scheind zu funktionieren.

    Aber ich verbleibe mit einem System das nicht Startet!

    Ich habe den Verdacht das die UUID der HD nicht angepasst wurden.
    Die VersuchsHD ist eine WD und das Original eine Qurical, die ZwischenHD eine Samsung.

    Das Ergebnis auf der WD scheind auch gut, zumindest werden alle Partitionen angelegt und gefüllt.

    Der Startversuch endet mit GRUB C, c mit so einem Harken darunter.
    Auf der Samsung wird das Rettungssystem auch startfähig erstellt, die Startet auch brav.

    Die Sicherung erstelle ich so und in dieser Reihenfolge:
    rear -C basic_system mkbackup
    rear -C home_backup mkbackuponly
    rear -C basic_system mkrescue

    das Restaurieren so und in der Reihenfolge:
    rear -C basic_system recover
    rear -C home_backup restoreonly

    /etc/rear/ enthält die Dateien, die auf das System anzupassen sind und lauten:

    Quellcode

    1. local.conf
    2. ### write the rescue initramfs to USB and update the USB bootloaderOUTPUT=USB### create a backup using the internal NETFS method, using 'tar'BACKUP=NETFS### write both rescue image and backup to the device labeled REAR-000BACKUP_URL=usb:///dev/disk/by-label/REAR-000




    Quellcode

    1. basic_system.conf
    2. this_file_name=$( basename ${BASH_SOURCE[0]} )LOGFILE="$LOG_DIR/rear-$HOSTNAME-$WORKFLOW-${this_file_name%.*}.log"BACKUP_PROG_EXCLUDE=( "${BACKUP_PROG_EXCLUDE[@]}" '/home/*' '/opt/*' )BACKUP_PROG_ARCHIVE="backup-${this_file_name%.*}"

    Quellcode

    1. home_backup.conf
    2. this_file_name=$( basename ${BASH_SOURCE[0]} )LOGFILE="$LOG_DIR/rear-$HOSTNAME-$WORKFLOW-${this_file_name%.*}.log"BACKUP_ONLY_INCLUDE="yes"BACKUP_PROG_INCLUDE=( '/home/*' )BACKUP_PROG_ARCHIVE="backup-${this_file_name%.*}"



    Nein, die Kommandos habe ich nicht selber ausgedacht.
    Hab ich abgeschrieben (cut und paste) aus dem User Guide / Multiple-Backups Link von Sauerland oben!

    Ich werde nun noch etwas herum-pfuschen um ggv die UUIDs im Grub und fstab zu überprüfen und wenn es das
    ist, auch berichtigen.

    Ich würde ja gern das System aus dem rescue starten aber wenn die UUIDs nicht passen wird das wohl
    auch scheitern.


    Vorschläge sind wie immer sehr willkommen.


    Ahoi von hier aus

    Für den Inhalt des Beitrages 136986 haftet ausdrücklich der jeweilige Autor: leon_herford

  • Neu

    Hier habe ich die IDs mit blkid verglichen.

    Quellcode

    1. /dev/sda1: SEC_TYPE="msdos" LABEL="BOOT-EFI" UUID="D2E0-9CC7" TYPE="vfat" PARTUUID="4a03af93-3fe9-44b7-8679-775b4bdd8289"
    2. /dev/sdf1: SEC_TYPE="msdos" LABEL="BOOT-EFI" UUID="B54D-1CA0" TYPE="vfat" PARTLABEL="sda1" PARTUUID="9a50f750-58e4-4bd6-b6de-8c407be0e32e"
    3. /dev/sda2: LABEL="SuSe-Sys" UUID="6ae8174d-b603-49a3-93a1-24437143467b" TYPE="ext4" PTTYPE="dos" PARTUUID="000aa0d6-a9cb-4381-8de4-5981c3334748"
    4. /dev/sdf2: LABEL="SuSe-Sys" UUID="6ae8174d-b603-49a3-93a1-24437143467b" TYPE="ext4" PARTLABEL="sda2" PARTUUID="3ce7c037-e74a-49ee-a317-7b10387488a9"
    5. /dev/sda3: LABEL="Home" UUID="8ff1065c-68c1-4a4b-8dbb-84ff1c345f65" TYPE="ext4" PARTUUID="9e64ed68-3eae-4425-bc58-45da5c5a74d5"
    6. /dev/sdf3: LABEL="Home" UUID="8ff1065c-68c1-4a4b-8dbb-84ff1c345f65" TYPE="ext4" PARTLABEL="sda3" PARTUUID="992d1076-e711-4c89-8be0-e6f345d11f39"
    sda ist das original
    sdf ist die Kopie

    bis auf die LABEL= BOOT-EFI, ist es so wie es sein sollte, glaub ich.

    Wie könnte ich nun das "Kaputte" System starten um dann den GRUB2 zu installieren?

    Ich such mal nach der SuperGrub, und versuch mein Glück auf diese Weise.


    Ahoi von hier aus

    Für den Inhalt des Beitrages 136987 haftet ausdrücklich der jeweilige Autor: leon_herford

  • Neu

    Ich habe nur gesehen, dass du mich hier erwähnt hast und nur den letzten Beitrag gelesen.

    Die UUIDs dienen lediglich der exakten Identifizierung einer Partition. Man kann jederzeit bei allen Tools Strings, wie UUID=Halligalli durch den jeweiligen Gerätenamen ersetzen.
    Also einfach die UUID Parameter durch die tatsächlichen Laufwerksbezeichnungen ersetzen.
    Dein Freund ist als root: lsblk -l -o NAME,FSTYPE,LABEL,UUID

    Damit kannst du deine Grub- Bootzeile entsprechend anpassen.
    Wenn du das System damit nach Gusto "restauriert" hast, kannst du das einfach mit YaST/update-grub etc. wieder ändern.

    Also einfach mit einem Rescuesystem booten und die benötigten Infos mit lsblk anzeigen lassen.
    Die Partitionen, die du brauchst, dann einfach Probe- Mounten, damit du prüfen kannst, welche UUID tatsächlich der Partition zugeordnet ist, die dann mit /dev/sdXY mountest.
    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 136988 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • Neu

    @Berichtigung

    Danke für die Hinweise. Das hilft mir weiter, obwohl ich den verdacht habe das Grub2 nicht ordentlich installiert worden ist.

    Ich habe schon an anderer Stelle davon gelesen, das ReaR diese Kleinigkeit nicht immer ordentlich erledigen kann.
    Im recover-mode werden sehr viele angaben vom User gefordert, und ob ich das alles richtig beantwortet habe .... .
    Diesen Umstand muss ich noch genauer überprüfen.


    Ahoi von hier aus

    Für den Inhalt des Beitrages 137016 haftet ausdrücklich der jeweilige Autor: leon_herford