Beiträge von Spaceloop

    Was würdet ihr für ein Dateisystem nehmen für die Backupplatte? Ich habe klassischerweise ein Dual-Boot-System mit Windows. Das wird zwar nur alle paar Monate genutzt, dennoch sind auch da einige ältere Sachen drin, welche ich mitsichern möchte.


    Irgendwo habe ich etwas vom "kleinsten gemeinsamen Nenner" gelesen und eine Empfehlung, dafür auf NTFS zu setzen. Allerdings scheidet damit die Möglichkeit aus "mal eben" einen Zweig des Verzeichnisbaums aus Linux unkomprimiert rüberzukopieren. Denn sobald die Dateinamen bestimmte Zeichen enthalten, gibt es Ärger...


    Man könnte natürlich die Linux-Struktur in ein TAR oder ein DAR packen und auf NTFS sichern. Oder man formatiert ext4, und geht für solche Fälle grundsätzlich über Linux - zumal wenn man es eh 95% der Zeit nutzt. Suse-konform käme evtl. auch BTRFS in Betracht?

    Wahrscheinlich bekomme ich in 30 Jahren eher ein System zum Laufen, was sich auf ext4 versteht. Bei Windows könnten hingegen die Aktivierungsserver abgeschaltet sein o.ä.

    Hallo,

    danke für die Antworten. Ich denke, ich werde mal Deja-Dup testen.


    Eine Frage habe ich noch und würde gern wissen, was eure Meinung dazu ist:


    Ich habe mir mal die Liste von Backup-Software auf

    List of backup software - Wikipedia

    angesehen.


    Klare Kriterien sind natürlich FOSS mit möglichst offener Lizenz sowie Lauffähigkeit unter verschiedenen Betriebssystemen (Multi-Plattform).


    Als wie entscheidend schätzt ihr die verwendete Programmiersprache ein? Der Grund ist, dass z.B. Python sich recht schnell weiterentwickelt. Es dürfte auf die Dauer schwierig sein, eine Software, welche für Python 2.x geschrieben wurde, auf einem modernen System zum Laufen zu bekommen. Aber ist es besser, wenn man einen 20 Jahre alten C-Quellcode vorliegen hat? Theoretisch würde ich denken, wenn es ein einfaches Kommandozeilentool ist, kommt man evtl. mit einem make-install bei alten C-Code schneller zum Ziel. Allerdings: wenn das Tool grafisch und komplexer ist, wird es wieder eine Menge Abhängigkeiten benötigen, die es irgendwann nicht mehr gibt?


    Auf jeden Fall würde dieser Gedanke nahelegen: einfaches Kommandozeilentool, in C verfasst, gescriptet oder über sepatates GUI-Tool bedient... Oder wie sehr ihr das?


    Theoretisch könnte man in 20 Jahren natürlich auch einfach ein Leap 15.5-Image in einer VM installieren, und versuchen, die Backupdateien so wiederherzustellen. Allerdings müsste dieses Image bereits die Backupsoftware installiert haben. Am besten müsste man sich das aktuelle System inkl. Backupsoftware daher als Live-System sichern, z.B. mit Suse Studio Express oder Linux Live Kit...

    Hallo,


    angeregt von dem Thema der letzten Linux User, zermatere ich mir gerade den Kopf bezüglich sinnvoller Backup-Strategien. Backups des Haupt-PCs mache ich bisher eher ungeplant-sporadisch und würde das gerne ändern. :)


    1) Was soll gesichert werden?

    Es sollte nach meinem Verständnis reichen, /home zu sichern. Bei einem Ausfall des Datenträgers würde ich ansonsten Leap neu installieren. Nach der Philosophie werden also keine Teile des Betriebssystems gesichert. Frage: Ist diese Vorgehensweise sinnvoll? Für welche Zwecke sollte man ein Komplett-Image des Systems erstellen?


    2) Wann soll gesichert werden?

    Das ist bei mir auch ein wichtiger Punkt, weshalb es nur unregelmäßig zu Sicherungen kommt. Wenn ich das System starte, tue ich das zu einem bestimmten Zweck. Ich bin gewohnt, das System dann frei hoch- oder runterfahren zu können. Nur wenn ich Zeit habe und daran denke, erstelle ich vielleicht mal ein Backup. Auch will ich vermeiden, das System mit einer Backup-Aufgabe zu belasten. Während ich eigentlich etwas anderes tun will, wozu ich alle Ressourcen des PC benötige. Mein Plan: ich starte das Backup, wenn ich Wäsche bügle. Ich selbst bin dann hauptsächlich mit Bügeln beschäftigt, aber noch in der Nähe und für alle Fälle verfügbar. Während ich bügle oder anderer Hausarbeit nachgehe, brauche ich den PC nicht. Ich hoffe, so eine gewisse Routine reinzubekommen. Guter Plan oder sollte ein Backup doch automatisch gestartet werden? :S


    3) Wie wird gesichert?

    Aus dem "Userspace" oder von einem anderen System wie Clonezilla?

    Ich würde in das System starten, in dem das /home-Verzeichnis, was ich sichern möchte, liegt. Oder geht z.B. Clonezilla evtl. doch einfacher?


    4) Was wird gesichert Nr. II: Dateiberechtigungen

    Wenn es unter Linux nur um das Sichern eines /home-Verzeichnisses geht: Ist es dann ratsam, darauf zu achten, dass möglichst viele Dateiberechtigungen und Attribute mit gesichert werden? Oder schafft man sich damit tendenziell eher Ärger? X/


    5) Wie sollte das Backup strukturiert sein und welche Möglichkeiten bestehen? (hängt mit 4) zusammen)

    -ein 1:1-Image in einer Image-Datei

    -Sicherung der Dateistruktur z.B. in ein ZIP-Archiv, wobei einige Unix-Attribute verloren gehen werden?

    -Sicherung der Dateistruktur in ein Dar-Archiv, was für Backups und die Sicherung von Unix-Attributen entwickelt wurde?

    -1:1-rüberkopieren der Dateistruktur ohne Archiv


    -Verschlüsselung durch Kopieren des Archivs in einen Veracrypt-Container? Oder sollte man besser den Veracrypt-Container in ein Archiv packen?? :/

    -Anreicherung des Archivs oder des Veracrypt-Containers oder von beidem mit PAR2-Fehlerkorrekturdaten (par2cmdline)?


    Gibt es evtl. irgendwo gut funktionierende, einfach aufzusetzende Backup-Lösungen? z.B. ein Raspi weckt den PC über Netzwerk auf, startet via ssh ein Backup auf eine an ihn angeschlossene Platte und fährt den PC anschließend wieder runter?



    Habt ihr hierzu Tips, Erfahrungen und Meinungen?

    Unglaublich, aber seht selbst:


    SUSE Preserves Choice in Enterprise Linux by Forking RHEL with a $10+ Million Investment | SUSE
    Investment reinforces SUSE’s commitment to innovate and support SUSE Linux Enterprise distributions and related open source projects  SUSE plans to…
    www.suse.com

    SUSE Announces Its Forking RHEL, To Maintain A RHEL-Compatible Distro - Phoronix


    Ich frage mich was das soll. Es ist nicht der 1. April. Man hätte gemütlich zusehen können, wie sich Redhat aktuell selbst zerlegt. Stattdessen bindet man sich also jetzt zwei sehr unterschiedliche Enterprise-Distributionen(!) ans Bein. Ich sehe die Gefahr, dass man sowohl RHEL-Kunden nicht überzeugen können wird, als auch, das SLE und am Ende openSUSE darunter leiden wird.


    Als van Leeuwen von Redhat kam, hatte ich zuerst auch schon Befürchtungen, dass hier eine Art trojanisches Pferd kommt. Andererseits, so dachte ich mir damals, was soll schon passieren, Suse und openSUSE blicken ja auf eine seit Jahrzehnten entwickelte, absolut konkurrenzfähige Distributionsarchitektur zurück, also was soll schon passieren... Und ein bisschen frischer Wind wird dem Laden sicher guttun...


    Aber dieser Move lässt einen doch die Kinnlade runterklappen! Was man mit 10 Millionen Dollar im SLE/openSUSE-Universum hätte bewirken können. Einfach mal so eben locker gemacht, wer segnet das eigentlich ab? Ist SUSE für van Leeuwen nur eine Plattform zur Etablierung einer Art Gegen-Redhat, ohne Rücksicht auf langjährige Nutzer?

    Zur Ausgangsfrage: ich finde es auch sehr tragisch, weil mir ein konventionelles openSUSE am wenigsten Probleme macht. Eigentlich läuft es stabiler und vorhersehbarer als alle Windows-Installationen zuvor. Man muss halt nur mal gelegentlich ins Terminal und ein Zypper up (oder ein Zypper dup) absetzen.


    Und genau das ist der Punkt, wo es bei vielen betreuten Windows-Nutzern hapert.


    Man konnte sich nach meiner Erfahrung auch schon unter Windows den Mund fusselig reden (XP, 00er Jahre): "Wenn Java, Acrobat, Flash oder die Engine des Virenscanners ein Update anzeigen, solltest du zustimmen"! Und wenn man das System nach einem Jahr mal wieder vor sich hatte, war natürlich nichts geupdatet worden. ("keine Ahnung, was das soll" - "Aber hat du die Blasen mit den Hinweisen rechts unten nicht bemerkt?" - "Ja aber die sind irgendwie eh immer da..." :/ ). Inzwischen ist ja einiges weggefallen oder auf Auto-Update konfigurierbar - dann kommen aber wieder Fragen, warum sich x und y nun geändert hat... :smilie_pc_012:


    Deswegen ist ein Auto-Update des gesamten OS Pflicht, da hilft auch das Softwareaktualisierungs-Tray-Tool bei KDE unter Leap nichts - denn am Ende muss man ja noch manuell klicken.


    Transactional updates mit KDE unter Micro OS wäre eine super Alternative, wenn sie sich in der Praxis bewährt.

    Inspiriert von einem Bericht auf heise.de habe ich mich einmal mit GPT4All befasst. Im Prinzip ist es eine Art ChatGPT in Frei für zu Hause.


    Im Moment habe ich es auf dem Tumbleweed-Datenträger laufen. Ob es auf Leap geht, müsste ich noch prüfen. Es läuft nicht auf Leap, da es offenbar eine glibc ab 2.34 voraussetzt. Eine weitere Mindestvoraussetzung ist ein Prozessor, welcher AVX unterstützt.


    Hier kann man sich GPT4all frei herunterladen:

    https://gpt4all.io/index.html


    Der Ubuntu-Installer funktioniert auch unter Tumbleweed (getestet unter XFCE). Man muss ihn nur als ausführbar markieren, und aufrufen (er ist grafisch). Einschränkung: er beschwert sich dass er bei mir kein Desktop-Icon anlegen konnte. Die Meldung habe ich ignoriert.


    Standardmäßig installiert er sich ins User-Verzeichnis unter gpt4all. Das Mainatainance-Tool in diesem Verzeichnis ist ein Setup-Programm, mit dem sich grundlegende Komponenten nachinstallieren lassen (wie bei Windows).


    Das eigentliche Chat-Programm befindet sich unter /bin.


    Beim ersten Start hat er mir von selbst einige Sprachmodelle zum Download angeboten. Ich habe mich zunächst für das kleine gpt4all-j-v1.3-groovy entschieden (3,5 GB). Der Downloadmanager ist später auch im Hamburgermenü zu finden.


    Der erste Chat:


    Echt faszinierend, was bereits daheim mit einem freien 3,5 GB-Modell auf einem älteren Core i5 möglich ist. 8)

    linux:/home/geeko # zypper lr -d


    Ich habe gerade festgestellt: Die Curl-Pakete wurden zuletzt am 18. Mai mit einem Update versorgt, die Version ist

    8.0.1-150400.5.23.1.


    Es ist also noch nicht so lange her. Kann da ein Zusammenhang bestehen?


    Konsolenausgaben bitte in Code-Tags! Wer soll das lesen??

    Habt ihr eine Idee, wie folgendes Problem in Leap plötzlich zustande kommt:



    zypper ref
    Problem beim Abrufen der Dateien von 'NVIDIA'.
    Fehler beim Download (curl) für 'https://download.nvidia.com/opensuse/leap/15.4/repodata/repomd.xml':
    Fehlercode: 'Curl error 92'
    Fehlermeldung: 'HTTP/2 stream 5 was not closed cleanly: PROTOCOL_ERROR (err 1)'

    Verlauf:
    - Gebe nach 3 Versuchen auf.

    In der Fehlermeldung oben finden Sie einen entsprechenden Hinweis.
    Repository 'NVIDIA' wird aufgrund des obigen Fehlers übersprungen.

    Repository 'SoftMaker' ist aktuell.
    Repository 'openSUSE:Leap:15.4:NonFree' ist aktuell.
    Repository 'openSUSE:Leap:15.4:Update' ist aktuell.
    Metadaten von Repository 'games' abrufen .......................................................................................................................................[fertig]
    Cache für Repository 'games' erzeugen ..........................................................................................................................................[fertig]
    Metadaten von Repository 'SUSE:SLE-15:Update' abrufen ..........................................................................................................................[Fehler]
    Repository 'SUSE:SLE-15:Update' ist ungültig.
    [https-download.opensuse.org-76c24f8b|https://download.opensuse.org/update/leap/15.4/sle] Keine gültigen Metadaten bei dem festgelegten URL gefunden
    Verlauf:
    - Zeitüberschreitung beim Zugriff auf 'https://download.opensuse.org/update/leap/15.4/sle/repodata/2f12fd8777b6c6e80fea5f1316b1a4a4e738e39c904b68a6c3ae13a6b5e39541-updateinfo.xml.gz'.
    - Can't provide ./repodata/2f12fd8777b6c6e80fea5f1316b1a4a4e738e39c904b68a6c3ae13a6b5e39541-updateinfo.xml.gz

    Überprüfen Sie, ob die für dieses Repository bestimmten URIs auf ein gültiges Repository verweisen.
    Repository 'SUSE:SLE-15:Update' wird aufgrund des obigen Fehlers übersprungen.
    Repository 'games:tools' ist aktuell.
    Repository 'openSUSE-Leap-15.4-1' ist aktuell.
    Metadaten von Repository 'Packman' abrufen .....................................................................................................................................[fertig]
    Cache für Repository 'Packman' erzeugen ........................................................................................................................................[fertig]
    Metadaten von Repository 'Update repository of openSUSE Backports' abrufen .....................................................................................................[fertig]
    Cache für Repository 'Update repository of openSUSE Backports' erzeugen ........................................................................................................[fertig]
    Repository 'Non-OSS Repository' ist aktuell.
    Repository 'Haupt-Repository' ist aktuell.
    Metadaten von Repository 'Update repository with updates from SUSE Linux Enterprise 15' abrufen -------------------------------------------------------------------------------------[\]Metadaten von Repository 'Update repository with updates from SUSE Linux Enterprise 15' abrufen ................................................................................[fertig]
    Cache für Repository 'Update repository with updates from SUSE Linux Enterprise 15' erzeugen ...................................................................................[fertig]
    Repository 'Hauptaktualisierungs-Repository' ist aktuell.
    Repository 'Aktualisierungs-Repository (Nicht-Open-Source-Software)' ist aktuell.

    Einige der Repositorys konnten aufgrund eines Fehlers nicht aktualisiert werden.


    Da aus den anderen Repos offenbar ein Kernel-Update ansteht, aber ich den NVidia-Treiber nicht aktualisieren kann, ist mir derzeit die Durchführung von zypper up zu riskant.