Datensicherung


B

Benutzer007

#1
Hallo,

momentan sieht die Datensicherung auf einem älteren Rechner mit Suse Linux 13.01 bei einer Verwandten wie folgt aus:

Code:
rsync -abuv --progress /home/user1 /home/backup --exclude "user1/.cache/" --exclude "user1/.cache/google-chrome/Default/Cache/" --exclude "/home/user1/.mozilla/firefox/Crash Reports" --exclude "user1/.cache/mozilla/firefox" --stats

find /tmp -maxdepth 1 -mindepth 1 -print0 | xargs -0r rm -rf
Wie gesagt, es ist ein älterer Rechner mit alten Platten. Bei einem der letzten Suse-Updates ist irgendgetwas schief gegangen. die Sicherungsplatte wurde plötzlich nicht mehr erkannt, sie war aus irgenwelchen Gründen nicht mehr gemountet. Datensicherung war also nicht möglich.

Wir haben nun - sicher ist sicher - eine weitere Platte angeschafft und planen neben der normalen wieder fehlerfrei laufenden normalen Sicherung, die beiden internen Platten noch zusätzlich je komplett auf je eine Partition der externen Platte zu sichern. Beide alten Platten sind unter 200 GB.
Wie würde man am besten vorgehen, so wie oben aber direkt bei "/" beginnend? Und macht es so überhaupt Snn, um im Fall der Fälle - irgenetwas geht völlig schief - einfach den letzten Stand komplett über die alte Platte zu brennen? Gibt es andere bessere/praktikablere Möglichkeiten?

Merci im voraus. Bin für jeden Tipp dankbar, Systemsachen sind mir Greuel.

Grüße
 

sheel

I love Asm
#2
Hi

ein paar Infos fehlen:
Welche Partitionen gibts, und mit welchem Dateisystem?
(schnellste Antwort wäre, den Inhalt der Datei /etc/fstab hier rein zu kopieren)

Zur derzeitigen Backupmethode, wenn das so auf die gesamten Partitionen angewendet werden soll gehts schief. zB. werden einige wichtige Dateiattribute nicht kopiert, über Zeug wie /dev und Mountpoints wird einfach drübergefahren...und es hört sich so an, dass das rsync am laufenden System gemacht wird.Mit anderen Worten, gerade halbfertig geänderte Dateien werden in ihrem halben Zustand gesichert. Auf die Benutzerdateien beschränkt, wenn man nicht viel herumtut, kanns ja noch gehn, aber auf das gesamte OS ... würde mich nicht auf so ein Backup verlassen. (Bzw., es gibt schon auch Möglichkeiten Backups am laufenden System zu machen, mehr dazu weiter unten.)

Genaueres kann mit den fstab-Infos beantwortet werden, aber wenns bei rsync bleiben soll:
a) Backups von einer LiveCD aus machen, nicht am laufenden System
b) Jede Partition, klar
c) "rsync -axHAXE --delete /von /zu" (und keine excludes)

So ein Backup bei Bedarf wieder herzustellen geht analog dazu, mit der Ausnahme, dass man evt. Grub wiederherstellen muss/will (kommt darauf an wie platt das System ist bzw. ob man der noch vorhandenen Grub-Installation noch Funktionalität zutraut). Also zuerst Dateien alle wiederherstellen, und dann Grub. Weiß nicht, wie das bei Suse ist, evt. gibts auf der InstallationsCD eine einfache Möglichkeit dazu, sonst kann man es mit ein paar Konsolenbefehlen auch von einer LiveCD aus machen.

Und ja, ein Backup auf die Art bei Bedarf wieder einzuspielen macht schon Sinn. (hab ich in der Art auch schon oft gemacht, geht problemlos). Bzw. wenn ein Problem schon zum Backupzeitpunkt bestand und man es erst später bemerkt hat, ist das Problem natürlich auch im Backup. Aber das Risiko kann man wohl kaum vermeiden (man kann sich natürlich mehrere Backups von verschiedenen Zeitpunkten behalten, bzw. Diffdateien davon usw...geht hier zu weit)

Zur Backupherstellung am laufenden System: Ich vermute, deine Partitionen sind Ext4 ohne LVM oder Ähnliches, da gehts aus den oben beschriebenen Gründen nicht. Möglich ist es bei Dateisystemen, die sog. Snapshots unterstützen: Prinzipiell erstellt man kurz vor Backupbeginn einen Snapshot, und von da an wird bei allen Dateiänderungen auch die Originalfassung wo anders aufbehalten. Gesichert wird dann bei den Originalen, die sich trotz laufenden Computer nicht ändern. Nach Backup macht man den Snapshot wieder weg.
Ext4 kann das nicht, aber zB. Btrfs (oder auch LVM-Systeme, nur ist LVM ab und zu ein umständlicher Krampf). Wenn du deine Dateisysteme änderst könnte man das also machen (wie genau kann ich ja bei Bedarf noch genauer beschreiben)
 
B

Benutzer007

#3
Hej,

auf den anderen Rechner komme ich heute nicht mehr. Die externe Platte habe ich hier eben mit zwei 200GB-Partitionen ext2 formatiert.

Momentan wird vor dem Runterfahren des Systems gesichert, dann sollte nichts mehr offen sein. Es werden nur Anwenderdaten gesichert.

Ich melde mich wahrscheinlich morgen noch mal, weil ich dann die Daten bekommen kann.

Grüße
 
B

Benutzer007

#5
Hi Leute,

so, ich habe nun die Daten. Allerdings ist auf diesem Rechner irgendetwas super schief gelaufen, wie gesagt, irgendwann tat es die Backup Platte nicht mehr.

"fdisk -l" bringt nun Folgendes:

Code:
linux-fixp:~ # fdisk -l
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.

Disk /dev/sda: 160.0 GB, 160041885696 bytes, 312581808 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt


#         Start          End    Size  Type            Name
1         2048      4208639      2G  Linux swap      primary
2      4208640     46153727     20G  EFI System      primary
3     46153728    312580095    127G  Microsoft basic primary

Disk /dev/sdb: 80.0 GB, 80026361856 bytes, 156301488 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00022dae

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048   156301311    78149632   83  Linux
linux-fixp:~ #
Das sieht alles ganz merkwürdig aus. Wie man damit noch arbeiten kann, ist mir momentan ein Rätsel.

Ich habe ebenfalls Suse Linux 13.1 auf dem Rechner, bei mir kommt allerdings diese merkwürdige Meldung " GPT support is currently new" nicht. Vielleicht weil ich alle Updates hab laufen lassen, auf dem anderen Rechner wurden wegen der Macke 70 Updates nicht eingespielt.

Bei mir sieht das so aus:
Code:
linux-7jgt:~ # fdisk -l

Disk /dev/sda: 80.0 GB, 80026361856 bytes, 156301488 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes                                                                
I/O size (minimum/optimal): 512 bytes / 512 bytes                                                                    
Disk label type: dos                                                                                                 
Disk identifier: 0x000eed4d                                                                                          
                                                                                                                     
   Device Boot      Start         End      Blocks   Id  System                                                       
/dev/sda1            2048     4208639     2103296   82  Linux swap / Solaris
/dev/sda2   *     4208640    46153727    20972544   83  Linux
/dev/sda3        46153728   107593727    30720000   83  Linux
/dev/sda4       107593728   156301311    24353792   83  Linux
linux-7jgt:~ #
Wobei mich gerade Disk label type: dos und Disk identifier: 0x000eed4d etwas irritieren.
 

sheel

I love Asm
#6
Bitte /etc/fstab, oder auch die Ausgabe von "mount". fdisk zeigt keine Dateisysteme.
Bzw., du hast auch Windows (oder?): Soll die Sicherung das auch betreffen?

edit: Jedenfalls ist das ganze schon einmal suboptimal :D
GPT/MBR-Mischung, und 20GB für das Efi-Teil?
 
Zuletzt bearbeitet:
B

Benutzer007

#7
Auf beiden Rechern ist kein Windows installiert. Wie die Windows-Spuren da drauf kommen - keine Ahnung.

Der Rechner, um den es geht:

/etc/fstab
Code:
/dev/disk/by-id/ata-ST3160021A_3JS1ZP6E-part1 swap swap  defaults  0 0
/dev/disk/by-id/ata-ST3160021A_3JS1ZP6E-part2 / ext4  acl,user_xattr  1 1
/dev/disk/by-id/ata-ST3160021A_3JS1ZP6E-part3 /home ext4  acl,user_xattr  1 2
~
~
~
~
"/etc/fstab" 3L, 312C 3,1           All
Code:
linux-fixp:~ # mount
devtmpfs on /dev type devtmpfs (rw,relatime,size=761624k,nr_inodes=190406,mode=755)
tmpfs on /dev/shm type tmpfs (rw,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
/dev/sda2 on / type ext4 (rw,relatime,data=ordered)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
tmpfs on /var/run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
tmpfs on /var/lock type tmpfs (rw,nosuid,nodev,relatime,mode=755)
/dev/sda3 on /home type ext4 (rw,relatime,data=ordered)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)
gvfsd-fuse on /var/run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
linux-fixp:~ #
 
Zuletzt bearbeitet von einem Moderator:

sheel

I love Asm
#8
Hab gerade paar Sachen gelesen, dass einfach Umkonvertieren zu Btrfs mit Opensuse wohl nicht so
einfach wie bei Debianbasierten geht, weil das OS sich da eine ganz bestimmte Subvol-Struktur erwartet.
Naja.

Das Partitionensystem ist zwar ein Chaos, und eine der zwei Festplatten wird anscheinend überhaupt
nicht verwendet, aber wenns irgendwie geht... für einen sauberen Neustart wäre es vermutlich das
Einfachste, Opensuse neu zu installieren (und dabei ein paar Sachen gleich am Anfang beachten)

Zum Backup, es gibt also zwei wichtige ext4-Partitionen, / und /home auf sda2 und sda3.
a) Als Erstes die externe Platte von Ext2 auf Ext4 umstellen, wenns bei rsync bleiben soll.
Ext2 kann nicht alle Metadaten, es würde was verloren gehen

b) LiveCD starten, externe Platte anstecken

c) Ähnlich wie oben untersuchen, wie die interne Platte mit den drei Partitionen und die
externe Platte heißen (von LiveCDs aus ist es nicht ganz so sicher, ob das, was normalerweise
/dev/sda heißt, nicht plötzlich /dev/sdb oder so ist.) Ich nehme an, dass
/dev/sda nach wie vor /dev/sda ist und die externe Platte /dev/sdc heißt
(und genau die zwei Partitionen für das Backup hat)
[/dev/sdb ist dann vermutlich die ungenutzte interne Platte, ist egal]

d) Paar Konsolenbefehle (jeweils ohne Anführungszeichen):
"su" (Rootpasswort eingeben)
"mkdir /mnt/von" (sollte keine Fehlermeldung ergeben)
"mkdir /mnt/zu" (sollte keine Fehlermeldung ergeben)
"mount -t ext4 /dev/sda2 /mnt/von" (sollte keine Fehlermeldung ergeben)
"mount -t ext4 /dev/sdc1 /mnt/zu" (sollte keine Fehlermeldung ergeben)
"ls /mnt/von" (sollte paar Ordner und Dateinamen anzeigen. Wenn nichts kommt ists nicht gut)
"rsync -axHAXE --delete /mnt/von /mnt/zu" (dauert)
"umount /mnt/von"
"umount /mnt/zu"
"mount -t ext4 /dev/sda3 /mnt/von" (sollte keine Fehlermeldung ergeben)
"mount -t ext4 /dev/sdc2 /mnt/zu" (sollte keine Fehlermeldung ergeben)
"ls /mnt/von" (sollte paar Ordner und Dateinamen anzeigen. Wenn nichts kommt ists nicht gut)
"rsync -axHAXE --delete /mnt/von /mnt/zu" (dauert)
"umount /mnt/von"
"umount /mnt/zu"
"rmdir /mnt/von" (sollte keine Fehlermeldung ergeben)
"rmdir /mnt/zu" (sollte keine Fehlermeldung ergeben)
"exit"
Bei Bedarf geht das auch in eine Scriptdatei mit Fehlerkontrollen jeweils dazwischen,
dass man nicht immer alles eintippen muss.

LiveCD ausschalten, fertig.
 
B

Benutzer007

#9
Ich danke Dir mal erst.

Ich werde das Vorgehen mal erst irgendwo testen und mich dann wieder melden.

Wobei, ich sehe gerade, mein Rechner hat schon ext4:
Code:
/dev/disk/by-id/ata-HTS541080G9SA00_MPBDL0XNG8625M-part1 swap                 swap       defaults              0 0
/dev/disk/by-id/ata-HTS541080G9SA00_MPBDL0XNG8625M-part2 /                    ext4       acl,user_xattr        1 1
/dev/disk/by-id/ata-HTS541080G9SA00_MPBDL0XNG8625M-part3 /home                ext4       acl,user_xattr        1 2
/dev/disk/by-id/ata-HTS541080G9SA00_MPBDL0XNG8625M-part4 /home/backup         ext4       acl,user_xattr        1 2
 
#10
Wo siehst du das denn in der gerade gezeigten Ausgabe?
Jedenfalls, der linux-fixp-Rechner hat auch ext4,
nur die externe Festplatte nicht (laut dir, weiter oben).
 
B

Benutzer007

#11
Mein Rechner (linux-7jgt) ist nicht der, um den es geht (linux-fixp).
Wo siehst du das denn in der gerade gezeigten Ausgabe?
/etc/fstab
Ich habe das nur geschrieben, weil ja auf dem anderen Rechner so Sachen wie "EFI System" und "Microsoft basic" zu lesen sind (s.o.).
 
#12
Ja, das ist ziemlich durcheinander. Aber trotzdem hat linux-fixp
auch Ext4 auf den wichtigen Partitionen, sieht man auch ind er fstab-Datei
(und wenn das Linux damit startbar ist muss es wohl stimmen)
 
B

Benutzer007

#13
@sheel
Hi,
Du hattest da ja die Konsolenbefehle oben geschrieben.
Warum die dieses mkdir /mnt/von und mkdir /mnt/zu gemacht?
Steht von und zu für irgendetwas anderes, oder sollen die genauso genommen werden?
Ich weiß, ist ne blöde Frage, aber wie gesagt, Linux werde ich nie verstehen.
Grüße
 
#14
Was "mount" prinzipiell macht ist, den Inhalt irgendeiner angegebenen Partition als Inhalt eines bestehenden Ordners festzulegen. zB. kann man einen leeren Ordner /mein/ordner haben, und einen angeschlossenen USB-Stick dahin mounten, dann sieht man die Dateien und Ordner vom USb innerhalb von /mein/ordner. Während /mein und /mein/ordner auf deiner internen Festplatte sind ist alles in /mein/ordner am USB

Linuxsysteme haben ja ein paar vorgegebene Ordner, die jeweils für einen bestimmten Zweck gedacht sind, zB. /home für die eigenen Dateien der User, /boot für den Bootloader usw.usw. . Dabei gibt es auch /mnt, ein leerer Ordner, der nur dafür da ist, vom Benutzer zum Mounten von irgendwas verwendet zu werden. Wenn ich nur "kurz" was mounten will, ein paar Sachen mit den Dateien dort mach und das Ganze wieder auflöse ... rein technisch gehts in einem Unterordner in /home oder so genau so gut, aber wenn man schon ein /mnt hat, das dafür da ist...

Und zum "von" und "zu": Hier will ich jeweils zwei Partitionen gleichzeitig mounten (eine, die gesichert werden soll, und eine, wo die Sicherung hingeht). Zwei Ordner sind nötig, /mnt ist nur einer ... also selber Unterordner "von" und "zu" gemacht, und diese verwendet. Du kannst sie natürlich anders nennen.
 
B

Benutzer007

#15
Ich glaube langsam schnalle ich es...

Der Mount-Befehl sagt nichts über den Device selbst aus sondern nur, wo im Filesystem "eingehängt" wird. Sobald das Ding da drin ist - wo auch - kann man darauf zugreifen und Verzeichnisse erstellen oder auch nicht. Richtig?

Code:
rsync -axHAXE --delete /home/. /var/run/media/userxxx/ElementsPart3/BACKUP-DEV-SDA1
In diesem Fall war BACKUP-DEV-SDA1 gar nicht vorhanden, das Verzeichnis wurde mit dem Befehl erzeugt.
Eingehängt wurde in diesem Fall implizit durch das Anschließen via USB und bestätigen.


Du schreibst: ""mount -t ext4 /dev/sda2 /mnt/von"
Ich dachte immer, das Filesystem wird durch das Formatieren der Partition festgelegt.
Was wäre denn, wenn die Partitionen nicht mit ext4 sondern ext2 oder sonst was formtiert wären?
 
Zuletzt bearbeitet von einem Moderator:
#16
Der Mount-Befehl sagt nichts über den Device selbst aus sondern nur, wo im Filesystem "eingehängt" wird. Sobald das Ding da drin ist - wo auch - kann man darauf zugreifen und Verzeichnisse erstellen oder auch nicht. Richtig?
Genau.

Dass verschiedene Benutzer verschiedene Rechte (pro Ordner/Datei) haben können
verkompliziert die Sache zwar (ob man wirklich Verzeichnisse erstellen kann usw.),
aber prinzipiell stimmts.

In diesem Fall war BACKUP-DEV-SDA1 gar nicht vorhanden, das Verzeichnis wurde mit dem Befehl erzeugt. Eingehängt wurde in diesem Fall implizit durch das Anschließen via USB und bestätigen.
Ja. Übliche Linuxinstallation haben was dabei, dass automatisch das Anschließen von USBs, Einlegen von CDs usw. erkennt, dafür einen leeren Ordner macht und da reinmountet (bzw. je nach Einstellungen vorher auch nachfragt oder irgendwas). Für diese automatischen Sachen wird oft /media verwendet, während /mnt rein für die persönliche Verwendung vom Benutzer frei bleibt.

Für die Situation weiter oben (Zugriff auf die interne Festplatte von einer LiveCD aus)
greift die Automatik aber normalerweise nicht, deshalb händisch eingegebene Befehle.
 
#17
Du schreibst: ""mount -t ext4 /dev/sda2 /mnt/von"
Ich dachte immer, das Filesystem wird durch das Formatieren der Partition festgelegt.
Was wäre denn, wenn die Partitionen nicht mit ext4 sondern ext2 oder sonst was formtiert wären?
Das Dateisystem wird schon durchs Formatieren festgelegt, und der Teil "-t ext4" ist in dem Fall vermutlich sogar überflüssig (siehe weiter unten, warum). Mount muss für seine Arbeit Wissen, welches Dateisystem die angegebene Partition hat. Die Partition wird nicht geändert, und man kann nicht irgendwas angeben, es muss zur Partition passen.

Mount kann versuchen, den richtigen Typ selbst zu erkennen (wenn man einfach kein "-t irgendwas" angibt. Für Ext2/3/4 geht das auch sehr gut (deswegen ist die Angabe eigentlich überflüssig), bei manchen anderen Dateisysteme bekommt man eine Meldung dass nichts erkannt werden kann oder es mehrere Möglichkeiten gibt und man bitte selber was angeben soll.

Falsche Angaben führen meistens direkt zu Fehlermeldungen (weil mount kapiert, dass das nicht stimmen kann).
(Ext2/Ext3/Ext4 sind ein bisschen besonderns, weil sie gleich teilweise aufgebaut sind
und das Zugreifen mit einer höheren version als das echte Dateisystem der Partition
ohne Datenverlust geht. ... Egal.)
 
Zuletzt bearbeitet:

Neue Beiträge