Hallo Forum,
ich nutze seit einigen Tagen das neue 'Debian 8' mit der Desktopumgebung
'Gnome 3.14.1'. Eigentlich ein perfektes OS, allerdings habe ich meine
anfaenglichen Schwierigkeiten.
Als gebrandmarktes Kind, wollte ich, nachdem ich das System neu
aufgesetzt habe und die wichtigste Software aufgespielt habe, einen
Systemwiederherstellungspunkt oder etwas in der Art setzen, damit im
Fall der Faelle alles wieder leicht auf den Zeitpunkt 0 zurueckgesetzt
werden kann.
Hierzu schien es mir am einfachsten und sinnvollsten, mittels
1
sudo tar -cvpzf debian_backup.tar.gz --exclude/...
,
die meisten und wichtigsten Verzeichnisse zu sichern.
Die Rueckspielung sollte dann ueber
1
sudo tar -xvpzf debian_backup.tar.gz -C /
erfolgen.
Gestern Abend war es soweit. Nach der Installation von Bumblebee &
Nvidia Treiber hat das OS seinen Dienst verweigert und nach dem
Bootvorgang kam lediglich ein weißes Bild mit Smiley, mein System sei
irreparabel dahin.
Also habe ich 'tar' angeworfen, um alles wieder zurueckzusetzen, ohne
Erfolg. Nur eine Neuinstallation konnte helfen.
Jetzt die Frage, gibt es eine Software, eine Methode oder dergleichen,
mit der ich einfach einen schoenen Sicherungspunkt setzen kann und ohne
Probleme das System wieder in seinen Urzustand versetzen kann, sollte es
notwendig sein?
Das zweite Problem, was ich habe betrifft die Desktopumgebung. In Debian
8 muss man sich fuer alles moegliche Tweak-Tools installieren.
- Minimieren der Fenster erlauben (gnome-tweak-tool)
- Dateien auf dem Desktop erlauben (gnome-tweak-tool)
- Systemfarben aendern (gnome-color-chooser)
und und und.
Mein Problem ist jetzt, dass alles funktioniert und so eingestellt ist,
wie ich es mag, bis auf den Desktophintergrund.
Ich habe eine .png Datei, die nur Teile des Desktops einnimmt und die
transparenten Teile sollte durch die 'Grundfarbe des Desktops'
wiedergegeben werden. Hatte das mal unter Ubuntu, lief ohne Probleme.
Aktiviere ich mein Bild unter Debian, kann ich mir entweder eine .png
oder eine Desktophintergrundfarbe einstellen, aber nicht beides.
Nun habe ich mein System, wie oben beschrieben, zwei Mal in den
vergangenen Tagen aufgesetzt. Einmal war die 'Default' Farbe hinter
meiner Grafik 'blau', mal war sie 'schwarz'.
Nun habe ich die /etc durchforstet und versucht diese voreingestellte
Farbe zu finden und fuer mich anzupassen, leider ohne Erfolg.
Hat jemand einen Tipp, wie oder wo diese Farbe hinterlegt sein koennte
oder wie ich diese grundsaetzlich aendern kann?
Thanks in advance
Matthias
Mit btrfs als Filesystem kann man Snaphots anlegen und auch davon
booten. Das ersetzt keinen Backup, aber eignet sich für Experimente am
System.
Desktop-Eigenschaften sind üblicherweise im Benutzerkontext zu finden,
also nicht in /etc sondern irgendwo unter /home/DeinName.
A. K. schrieb:
>Mit btrfs als Filesystem kann man Snaphots anlegen und auch davon>booten. Das ersetzt keinen Backup, aber eignet sich für Experimente am>System.
Habe ext4 und wollte eigentlich nicht experimentieren, insbesondere
dann, wenn es nicht das ersetzt, was ich eigentlich wollte, eine Art
Backup.
Nicht das wir uns falsch verstehen, experimentieren ist okay, aber im
Notfall, will ich sicher gehen, dass alles tip top funktioniert.
Dazu kommt, ich moechte etwas standardmaessiges. Sollte es da nicht
etwas geben? Ich meine wir reden von etwas sehr elementarem.
Alexander S.:
>vielleicht solltest Du diese Fragen besser in...
Klar, ist auch eine Moeglichkeit, aber ich dachte, weil hier auch
explizit Software als Unterpunkt des Forums genannt wird, koennte ich es
auch hier probieren.
Matthias S. schrieb:> Nicht das wir uns falsch verstehen, experimentieren ist okay, aber im> Notfall, will ich sicher gehen, dass alles tip top funktioniert.
Ich wollte damit nicht btrfs als riskant hinstellen, sondern bezog mich
auf deine Experimente mit dem System, wie rumbasteln an Treibern. Das
ist mit System-Snapshots weniger riskant.
Habe es gerade mal ueberflogen.
Positiv finde ich, dass es eine Loesung aus den offiziellen Repositories
ist und das es sehr effizient zu sein scheint. Mit dem nachstehenden
Wiki, auch wenn es als 'Baustelle' markiert ist, habe ich auch schon mal
eine erste Anleitung.
https://wiki.debianforum.de/Snapshots_und_Backup_mit_btrfs
Was mich ehrlich gesagt im Moment noch stoert, dass ich mit diesem Weg
mein System noch einmal erneut aufsetzen muesste, dass wollte ich
eigentlich vermeiden.
Matthias S. schrieb:> Jetzt die Frage, gibt es eine Software, eine Methode oder> dergleichen, mit der ich einfach einen schoenen Sicherungspunkt> setzen kann und ohne Probleme das System wieder in seinen> Urzustand versetzen kann, sollte es notwendig sein?
Ja.
Partitioniere Deine Festplatte, dann kannst Du so viele
Installationen parallel haben, wie Du lustig bist.
Du kannst insbesondere eine zum Herumprobieren und eine
zum Arbeiten haben.
Snapshots kannst Du übrigens mit dd anlegen. - Nein, das ist
kein dummer Witz; die Methode ist zwar urtümlich, funktioniert
aber zuverlässig.
Possetitjel schrieb:
>Du kannst insbesondere eine zum Herumprobieren und eine>zum Arbeiten haben.
Ich wollte gar nicht rumprobieren oder experimentieren, ist halt einfach
was in die Hose gegangen.
>Snapshots kannst Du übrigens mit dd anlegen. - Nein, das ist>kein dummer Witz; die Methode ist zwar urtümlich, funktioniert>aber zuverlässig.
Glaube ich bzw. weiß ich. Nur bin ich gerade etwas skeptisch, weil ich
ja schon vorgesorgt hatte. 'tar' haette eigentlich auch todsicher sein
sollen. Das Backup war auf einer anderen physischen Partition, also
alles in Ordnung dachte ich.
Als es dann so weit war ging es ueber den Recovery-Mode in die Shell und
das rueckspielen sah auch gut aus. Die verbose-Rueckmeldungen von 'tar'
waren alle in Ordnung, aber dennoch murks.
Das 'dd' auch eine Alternative ist, habe ich via Suchmaschine in
Erfahrung gebracht, aber da 'tar' schon nicht funktionierte wieder
verworfen. Und da ich in diesem Punkt nicht experimentieren wollte,
dachte ich, ich frag mal nach.
Debian 8 ist neu, da war der Gedanke, dass es eine, sagen wir
zeitgemaessere Methode zum sichern gibt.
Matthias S. schrieb:> Possetitjel schrieb:>>>Du kannst insbesondere eine zum Herumprobieren und eine>>zum Arbeiten haben.>> Ich wollte gar nicht rumprobieren oder experimentieren,> ist halt einfach was in die Hose gegangen.
Naja... einen Treiber zu installieren, der dazu führen kann,
dass das System nicht mehr startet, ist per definition ein
gewagtes Experiment :)
Im übrigen vermute ich, dass Dein System sehr wohl noch
gestartet ist, nur X bzw. Gnome wird nicht mehr richtig
funktioniert haben. Ohne diesen dämlichen Display Manager
wäre die Fehlersuche vermutlich leichter gewesen; da hättest
Du Dich normal an der Textkonsole anmelden können.
>>Snapshots kannst Du übrigens mit dd anlegen. - Nein, das ist>>kein dummer Witz; die Methode ist zwar urtümlich, funktioniert>>aber zuverlässig.>> Glaube ich bzw. weiß ich. Nur bin ich gerade etwas skeptisch,> weil ich ja schon vorgesorgt hatte.
Nicht so schnell in's Bockshorn jagen lassen...
> 'tar' haette eigentlich auch todsicher sein sollen.
Hmm... also bei tar vermute ich immer zahlreiche Fallen,
seien dies nun die Behandlung von Links, Device-Files,
absoluten Pfaden oder geöffneten Dateien.
Bei meinen User-Daten (/home/*) macht tar immer genau das,
was ich will, aber zur Systemwiederherstellung würde ich es
nicht verwenden.
> Das Backup war auf einer anderen physischen Partition, also> alles in Ordnung dachte ich.
Ja, das ist ja auch okay.
> Als es dann so weit war ging es ueber den Recovery-Mode in> die Shell und das rueckspielen sah auch gut aus. Die> verbose-Rueckmeldungen von 'tar' waren alle in Ordnung, aber> dennoch murks.
Kann ich nix zu sagen.
> Das 'dd' auch eine Alternative ist, habe ich via Suchmaschine> in Erfahrung gebracht, aber da 'tar' schon nicht funktionierte> wieder verworfen.
Unsinn. Nicht so viel auf Voodoo geben.
Linux ist nicht Windows. Man kann i.d.R. herausfinden, was
schiefgelaufen ist - allerdings kostet das Arbeit, d.h. Zeit,
Geduld und Hirnschmalz.
> Und da ich in diesem Punkt nicht experimentieren wollte,> dachte ich, ich frag mal nach.
Ich kann nur von meiner Erfahrung berichten.
Tar arbeitet (zumindest der Wirkung nach) "oberhalb" des
Dateisystems, kennt und respektiert also Dateigrenzen,
Eigentümer, Attribute und so fort. Ich verwende es NUR für
User-Daten; dort macht es allerdings genau das, was ich will.
Für Systemdateien setze ich es generell nicht ein.
dd arbeitet "unterhalb" des Dateisystems, greift also direkt
auf die Blöcke innerhalb der Partition zu. Die Kopie, die
von dd erstellt wird, ist also bitgleich zum Original; das
Filesystem und der Inhalt der Dateien ist völlig belanglos.
Ich habe mit dd vor längerer Zeit WindowsXP-Rechner gegen
unbeabsichtigte Veränderung gehärtet: Mit dd einen Abzug der
Windows-Partition erstellt, bei Bedarf mit dd zurückgespielt.
Funktionierte zuverlässig.
> Debian 8 ist neu, da war der Gedanke, dass es eine, sagen> wir zeitgemaessere Methode zum sichern gibt.
Tja... sagen wir so: Eine urtümliche Methode, die
a) ich verstehe und
b) die mit Standard-Werkzeugen auskommt
ist mir lieber als ein Super-Duper-Tool, das mit jeder Version
anders heißt, anders funktioniert und andere Fehler hat.
Statt dd kannst du auch Snapshots verwenden, falls du LVM benutzt. dd
ist ein bisschen wackelig, wenn du es bei einem Live-System nutzt - wenn
sich da zwischendrin Daten ändern, bekommst du einen inkonsistenten
Abzug.
Clone schrieb:> Versuch mal Clonezilla -> http://clonezilla.org> Ist ne nette Backup Lösung, verwendet soweit ich weiss auch das genannte> dd.
Clonezilla hat gegenüber dd den Vorzug, dass nur der belegte Inhalt
kopiert wird, und das auch noch komprimiert.
>Naja... einen Treiber zu installieren, der dazu führen kann,>dass das System nicht mehr startet, ist per definition ein>gewagtes Experiment :)
Auch war. Wobei, wenn ich mal mit Treibern Probleme habe, insbesondere
aus dem proprietaeren Bereich, dann mit Nvidia... Aber wie Linus T.
schon treffend sagte, "Nvidia, Fu...!".
>Ohne diesen dämlichen Display Manager>wäre die Fehlersuche vermutlich leichter gewesen; da hättest>Du Dich normal an der Textkonsole anmelden können.
Ich konnte noch in die Konsole. Allerdings wurde ich dann etwas blass,
nachdem die vermeintliche Sicherung nicht das hergab, was sie sollte und
ich aus den SystemLogs nicht wirklich schlau geworden bin. Hatte
eigentlich gerade eine ganz andere Baustelle am Laufen und dachte, hey,
mal eben die Grafikkarte einrichten...Yeah
>Nicht so schnell in's Bockshorn jagen lassen...
Im Gegenteil, deswegen finde ich Linux super, voellige Freiheit,
gleichzeitig eben auch Verantwortung, vorausgesetzt man arbeitet sich in
die Brocken ein. Nur leider muss man das immer dann machen, wenn man
keine Zeit hat, dafuer aber was schief gegangen ist.
>Tar arbeitet (zumindest der Wirkung nach) "oberhalb" des>Dateisystems, kennt und respektiert also Dateigrenzen,>Eigentümer, Attribute und so fort.
Deshalb habe ich ja auch die Option tar -p uebernommen, weil damit
eigentlich alle Berechtigungen etc. der zu sichernden Daten uebernommen
werden, also im Prinzip 1 zu 1 auf das tarball uebertragen werden.
>ist mir lieber als ein Super-Duper-Tool, das mit jeder Version>anders heißt, anders funktioniert und andere Fehler hat.
Wohl war, aber haette ja sein koennen, dass es was seit den letzten
Stable Versionen gibt, was ausgreift, etabliert und gut anwendbar ist.
Also mittelfristig werde ich jetzt mal btrfs ins Auge fassen, wenn ich
mein System wieder neu aufsetze, aber kurzfristig werde ich mich 'dd' an
die Sache begeben.
Was nachweislich geht, weil schon mal bei defekter Sysdisk verwendet:
älteres Clonezilla-Image restored und Filesicherung mit vmtl. tar drüber
gebügelt. Sollte aber noch das gleiche System sein, nur neuer.
Da Clonezilla offline arbeitet ist es recht umständlich, ein
Einzelfilerestore erst recht. Also ist es kaum für Routinebackups
geeignet. Deutlich besser eignet sich da rsnapshot.
René K. schrieb:> dd ist ein bisschen wackelig, wenn du es bei einem Live-System> nutzt [...]
Ja.
Ich verwende dd nur für Partitionen, die nicht gemountet sind,
also nicht zum laufenden System gehören. Hätte ich vielleicht
draufhinweisen sollen.
A. K. schrieb:> Da Clonezilla offline arbeitet [...]
Was bedeutet das in dem Zusammenhang?
"Funktioniert nicht auf Partitionen des eigenen Systems
(=momentan schreibbar gemounteten Filesystemen)"?
Wenn ja: Ist das nicht gerade der Knackpunkt beim Sichern von
Systemdateien?
Matthias S. schrieb:> Hat jemand einen Tipp, wie oder wo diese Farbe hinterlegt sein koennte> oder wie ich diese grundsaetzlich aendern kann?
dconf-editor dort nach desktop suchen und entspr. einstellungen
anpassen.
Bin jetzt zu faul das rauszusuchen, kommt auch darauf an was bei dir
verstellt ist. Evt. pfuscht da ein weiteres Programm rein....
Zum Backup wurde ja schon alles gesagt. Wenn du Snapshots mit dd oder
einem tool das darauf aufbau arbeitest, solltest du vorher den freien
Platz der zu backupenden Partition einmal ausnullen. D.h. bevor du das
Backuptool aufrufst schreibst du als user in das entspr. Dateisystem
eine (oder mehrere ) Datei ein immergleiches Zeichen. Danach wird die
Datei/en gelöscht und rufst machst dein Backup. Wenn das Programm die
Images komprimiert, ist es dadurch besser komprimierbar. Kannst dir
selber ein kleines Script schreiben dass das macht oder nimmst schon ein
entspr. Tool wie sfill, das du vor dem Backup aufrufst. Hast du eine
riesige Part mit viel freiem Platz kannst du entspr, Dummydateien
vorhalten die du wenn du mehr Platz brauchst einfach nach und nach
löschst. Dann dauert das 'ausnullen' vor jedem Backup nur kurz.
Possetitjel schrieb:> Snapshots kannst Du übrigens mit dd anlegen.
Nein. Nicht im laufenden Betrieb, also mit eingehängtem Dateisystem.
Das ist meilenweit von echten Snapshots entfernt.
Possetitjel schrieb:
>Ich verwende dd nur für Partitionen, die nicht gemountet sind,>also nicht zum laufenden System gehören.
Das System ist leider gemountet. Aber was anderes, noch mal wegen 'tar'.
Hat jemand Erfahrungen damit oder kann mir vielleicht sagen, wieso es
bei mir nicht funktioniert hat?
dd oder tar waeren deshalb optimal, weil ich die Rettung so ueber die
Konsole machen koennte, was das einzige ist, was im Notfall zur
Verfuegung steht. Geht mit anderer Software sicher auch ueber die
Konsole, aber die beiden genannten faende ich besser.
Hier meine tar-Befehle
Possetitjel schrieb:>> Da Clonezilla offline arbeitet [...]>> Was bedeutet das in dem Zusammenhang?
Bootstick/CD.
> Wenn ja: Ist das nicht gerade der Knackpunkt beim Sichern von> Systemdateien?
Entweder dies, oder Snapshots. Letztere gibt es in Windows (siehe auch
Systemwiederherstellungspunkt) und es erlaubt dort konsistente
Systemsicherungen im Betrieb, also online.
Matthias S. schrieb:> Possetitjel schrieb:>>>Ich verwende dd nur für Partitionen, die nicht gemountet sind,>>also nicht zum laufenden System gehören.>> Das System ist leider gemountet.
Ich weiss.
Das war auch anders gemeint: Installiere Dir (auf eine andere
Partition) ein Rettungssystem, oder verwende z.B. Knoppix. Dann
ist die Partition, die Du sichern willst, nicht mehr gemountet.
Das ist zumindest MEINE Lösung für das Problem. Snapshots mache
ich immer nur von anderen; Selfies will ich nicht.
sackjucken schrieb:> MWenn du Snapshots mit dd
Diesen Begriff sollte man heute nur im Kontext dazu fähiger
File/Disksysteme verwenden. Ihn auch für Offline-Imagebackups zu
verwenden verwirrt eher.
Matthias S. schrieb:> Hat jemand Erfahrungen damit oder kann mir vielleicht sagen, wieso es> bei mir nicht funktioniert hat?
Das kommt darauf an was du sonst noch gemacht hast. Mit tar muss man
später händisch noch einiges nacharbeiten. Das ist z.T. distroabhängig.
Keine Ahnung was du da genau gemacht hast. Theoretisch müsste es
funktionieren was du da angeben hast ich schätze mal du hast noch ein
paar andere Dinge gemacht die du vergessen hast, vergessen zu erwähnen.
Evt. hat tar manches nicht sauber restored, weil ein Lock auf den
Dateien war,... vermutlich der nvidiatreiber tja und dann kracht es
eben.
Sowas spielt man auch von einem Notsystem aus ein / macht ein chroot,...
und bügelt das nicht (halb) live drüber, das hast du sicher beachtet
oder?
sackjucken schrieb:
>Sowas spielt man auch von einem Notsystem aus ein / macht ein chroot,...>und bügelt das nicht (halb) live drüber, das hast du sicher beachtet>oder?
Nein, ueber Grub in die Console und dann den tar-Befehl zum
Zurueckspielen.
>Keine Ahnung was du da genau gemacht hast.
Bevor ich das tar genutzt habe, habe ich noch versucht, die zuvor
installierten GraKa Sachen zu purgen.
Jetzt daemmert es mir, ich haette lieber ein live-System starten sollen,
die Platte mounten und dann auf tar zurueckgreifen sollen.
Oder habe ich jetzt das beruehmte Brett vor dem Kopf?
Matthias S. schrieb:> Jetzt daemmert es mir, ich haette lieber ein live-System> starten sollen, die Platte mounten und dann auf tar> zurueckgreifen sollen.
Genau.
Oder - alternativ dazu - VORHER auf einer anderen Partition
ein Minimalsystem installieren, dass Du im Falle eines Falles
über GRUB starten kannst. Muss ja nur Terminalzugang haben.
> Oder habe ich jetzt das beruehmte Brett vor dem Kopf?
Nein, jetzt nicht mehr :)
Matthias S. schrieb:> Zu meiner Verteidigung.
Ohh... entschuldigung, ich wollte Dich gar nicht angreifen.
Jeder zahlt irgendwann Lehrgeld; das geht mir nicht anders.
> Die Idee tar zu nutzen und das ueber die grub shell zu> recovern, habe ich von den offiziellen Ubuntu Seiten.
Hmm... wenn grub tatsächlich eine eigene Shell hat und auch
das Standard-tar startet, sollte es eigentlich funktionieren.
Ahh... nein... Moment... hast Du das Backup AUCH von der
grub-shell aus gemacht? Sonst könnte es nämlich sein, dass
das Problem schon beim Backup und nicht erst beim Restore
verursacht wurde.
Possetitjel schrieb:
> ...hast Du das Backup AUCH von der grub-shell aus gemacht?
Nein, aus dem laufenden Desktopbetrieb heraus.
>Hmm... wenn grub tatsächlich eine eigene Shell hat und auch>das Standard-tar startet, sollte es eigentlich funktionieren.
Ich nehme an, dass es eine Grub Shell ist.
Ich habe mir gerade einen Live Stick fertig gemacht und werde jetzt das
Experiment wagen, dass Tarball ein weiteres Mal zurueckzuspielen.
tar laeuft ueber die Konsole, ist standardmaessig auf allen Systemen
vorhanden und die Umsetzung ist einfach.
Wenn es wieder nicht klappen sollte, werde ich es mit 'dd' machen, weil
ueber das live-System das eigentliche System ausgehaengt ist, dass war
ja die Voraussetzung.
Wenn ich den Threat gleich symbolisch schließe, hatte ich Erfolg, wenn
nicht, ... daran will ich jetzt gar nicht denken ;-)
Ich habe eine Nachtschicht eingeschoben, weil mich das Thema total
angefixt hat.
-SOLVED- zumindest was das Thema Backup angeht
tar eignet sich perfekt zur Erstellung eines vollstaendigen
System-Backups.
Das vorhin schon angeklungene Problem bestand einfach darin, dass ich
faelschlicherweise versucht habe, dass Tarball im Live Modus in der Grub
Shell zurueckzuspielen, was nicht geht.
Also ein Live-System gestartet, den Datentraeger gemounted und das
Tarball entpackt. Fertig, System wiederhergestellt.
Aufgrund der obigen Debatte hier noch einmal die funktionierende
Variante mittels 'tar' fuer diejenigen, die es ausprobieren oder nutzen
wollen.
1
sudo tar -cvpzf BACKUPNAME.tar.gz --exclude=/bin + ... + --exclude=/dev
2
3
,wobei
4
- c -> erstellen oder ueberschreiben der Sicherungsdatei
5
- v -> weist tar an, Status-Meldungen ueber die Shell auszugeben
6
- p -> uebernimmt alle Berechtigungen der zu sichernden Dateien/Verzeichnisse
7
- z -> komprimiert die in dem tarball zu speichernden Daten
8
- f -> name des tarballs
9
10
sudo tar -xvpzf debian_backup.tar.gz -C /MOUNTVERZEICHNIS
11
12
,wobei
13
- x -> der Befehl zum extrahieren
14
- v -> weist tar an, Status-Meldungen ueber die Shell auszugeben
15
- p -> uebertraegt alle Berechtigungen der zu schreibenden Dateien/Verzeichnisse
16
- z -> dekomprimiert die komprimierten Daten
17
- f -> name des tarballs
18
- C -> der Ort an den extrahiert werden soll
Wenn man das in ein Skript tuetet, hat man eine 1A Backup Absicherung
Matthias S. schrieb:> Ich habe eine Nachtschicht eingeschoben, weil mich das Thema total> angefixt hat.>> -SOLVED- zumindest was das Thema Backup angeht>> tar eignet sich perfekt zur Erstellung eines vollstaendigen> System-Backups.
Die ganzen excludes kannst du in eine Datei eintragen,
ist übersichtlicher. Diese kannst du dann mit -X meineExcludes.txt
angeben.
Nach dem Restore musst du die Verzeichnisse die excluded wurden evt
wieder
anlegen. Also mkdir /proc /sys /mnt /media usw
Siehe: https://help.ubuntu.com/community/BackupYourSystem/TAR
Unter Debian wird es nicht viel anders sein.
Das ist jetzt alles Jacke wie Hose, hauptsache läuft. Wie gesagt, ich
werde mi ein Sicherungs- und ein Aufspielskript machen, dann entfaellt
auch noch die Tipparbeit.
Wegen der anderen Sache nochmal
sackjucken schrieb:
>dconf-editor dort nach desktop suchen und entspr. einstellungen>anpassen.
dconf-editor ist bei mir komplett leer. Den Reiter 'Desktop' finde ich
zwar, aber leider ist der leer.
Hast Du vielleicht noch einen anderen Tipp?
Hallo Matthias,
Matthias S. schrieb:> Das ist jetzt alles Jacke wie Hose, hauptsache läuft. Wie gesagt, ich> werde mi ein Sicherungs- und ein Aufspielskript machen, dann entfaellt> auch noch die Tipparbeit.
Normalerweise reicht es, die Benutzerdaten in /home sowie systemseitig
/etc, /usr/local, /usr/src und /opt zu sichern. Vorausgesetzt, man hat
eine aktuelle Liste der installierten Pakete (dpkg --get-selections) und
aktuelle Datendumps von Software, die ihre Daten unter /var speichert --
zum Beispiel Datenbank-Server wie PostgreSQL, MySQL, Redis, Riak,
OpenLDAP uä.
Tipp: statt direkt in einen komprimierten Tarball zu schreiben ("tar
cpzf out.tar.gz /etc /usr/local /usr/src /opt") lieber STDOUT ("-") als
Ziel angeben und das auf pigz(1) pipen: "tar cpzf - /etc /usr/local
/usr/src /opt | pigz -p4 > out.tar.gz"; umgekehrt natürlich genauso. Das
komprimiert die Daten parallel und beschleunigt die Sache damit um den
Faktor 2 bis 4, je nach Performance der beteiligten Festplatten oder
SSDs.
HTH,
Karl
Karl Käfer schrieb:
>Hallo Matthias,
Hallo Karl.
Die Selektion der eigentlich wichtigen Verzeichnisse wollte ich machen,
habe mich dann aber entschieden, alles zu sichern, abgesehen von Videos,
Downloads & Co. -den Fehler habe ich bei meinem ersten Anlauf gemacht
:-))-
In uns home liegt bspw. eine .vimrc, der Apache hatte meine ich mal was
unter /var/spool -glaub ich- abgespeichert usw... Da ist es mir lieber
ich sichere ein Verzeichnis mehr als eines zu wenig. Insofern bin ich
dann auf der sicheren Seite.
Wegen der Effizienssteigerung wuerde ich ja machen, aber als ich die
letzte Sicherung gemacht habe, wie viel waren das, ein zwei Minuten
-direkt nach dem Aufsetzen mit rudimentärer Software-, wenn überhaupt,
insofern lohnt das fast gar nicht.
Allerdings habe ich das mal in meine hausinterne LinuxSupportFile
gepackt, da ich ja moeglicherweise auch mal etwas wirklich großes packen
will und es dann ausprobieren kann.
HTH dann :-)
[SOLVED]
Nachdem das erste Topic des Threats geloest wurde, hier die Loesung des
zweiten Problems, dass des Desktop-Backgrounds.
sackjucken schrieb:
>dconf-editor dort nach desktop suchen und entspr. einstellungen>anpassen.
Dieser 'Reiter' war in meinem Fall leer, daher habe ich die Suche nicht
fortgefuehrt.
Durch Zufall bin ich nun darauf gestoßen, dass sich die Hintergrundfarbe
des Desktops unter
'org' -> 'gnome' -> 'desktop' -> 'background'
befindet.
org habe ich einfach nicht damit assoziiert.
Hoffe das hilft, falls noch jemand das Problem hat.
Thread beobachten
Seitenaufteilung abschalten