Da btrfs die Dateiwiederherstellung bei versehentlicher Löschung im
/home Verzeichnis nicht möglich macht und wohl vor Zugriff, schützt
(obwohl man die nicht gelöschten gemountet bekommt und ansehen kann)
habe ich meine Dateien in einem neuen Ordner im Grundstamm außerhalb
des/home Verzeichnis (und dieses natürlich nicht als Standard
eingetragen, sondern nur in den Programmen in Benutzung).<br>Leider
scheint snapper auf dieses Verzeichnis zuzugreifen, wie kann ich in
snapper einstellen, dass es ein bestimmtes Verzeichnis nicht aufnimmt?
Hi,
schau mal in die man page von snapper:
Filters
Some files keep state information of the system, e.g. /etc/mtab. Such files should never be reverted. To help users, snapper allows one to ignore these files.
Each line in all files /etc/snapper/filters/*.txt specifies a pattern. When snapper computes the difference between two snapshots it ignores all files and directories matching any of those patterns by using fnmatch(3) with the flag FNM_LEADING_DIR.
Note that filters do not exclude files or directories from being snapshotted. For that, use subvolumes or mount points.
Beantwortet das deine Frage?
Der gesamte Text ist rätselhaft und ich verstehe kein Wort, obwohl ich snapper seit Jahren benutze und damit höchst zufrieden bin.
snapper ist standardmäßig nur für / (root) konfiguriert. /home ist davon ausgenommen wie man hier sieht:
**erlangen:~ #** btrfs subvolume list /home
ID 256 gen 98055 top level 5 path @
ID 257 gen 129504 top level 256 path @/var
ID 258 gen 129499 top level 256 path @/usr/local
ID 259 gen 113422 top level 256 path @/srv
ID 260 gen 129500 top level 256 path @/root
ID 261 gen 127176 top level 256 path @/opt
ID 262 gen 129506 top level 256 path @/home
ID 263 gen 111561 top level 256 path @/boot/grub2/x86_64-efi
ID 264 gen 50080 top level 256 path @/boot/grub2/i386-pc
ID 265 gen 129072 top level 256 path @/.snapshots
ID 266 gen 129502 top level 265 path @/.snapshots/1/snapshot
ID 587 gen 119109 top level 265 path @/.snapshots/272/snapshot
...
ID 627 gen 129060 top level 265 path @/.snapshots/312/snapshot
ID 628 gen 129071 top level 265 path @/.snapshots/313/snapshot
**erlangen:~ #**
Ein Benutzer kann aber jederzeit snapshots von allem machen:
**erlangen:~ #** btrfs subvolume snapshot /home test
**erlangen:~ #** btrfs subvolume show test
@/root/test
Name: test
UUID: d54b7506-c4a9-7442-bb4c-617bead46721
Parent UUID: 63085f28-85ec-0246-a40d-cf878e0fe83a
Received UUID: -
Creation time: 2022-03-08 09:00:21 +0100
Subvolume ID: 629
Generation: 129515
Gen at creation: 129514
Parent ID: 260
Top level ID: 260
Flags: -
Send transid: 0
Send time: 2022-03-08 09:00:21 +0100
Receive transid: 0
Receive time: -
Snapshot(s):
**erlangen:~ #**
Vermutlich fährst du am bestem, wenn du
- dich mit snapper vertraut machst
- eine Konfiguration für /home einrichtest
Nein btrfs verhindert die Wiederherstellung von gelöschten Dateien im /home bereich. Irgendein sicher für professionelle Nutzer nützlicher Schutz, insbesondere weil die mitlaufende Backups haben und keine Dateiwiederherstellung benötigen.
Daher hab ich meine Dateien nicht mehr in home, sondern in einem Ordner den ich auch nicht als “home” Bereich konfiguriert hab.
Also bleibt hiernach wohl nur eine neue,eigene Partition, oder kann Subvolume noch was anderes sein?
Ich bevorzüge noch immer ein separates Dateisystem für /home.
wenn man es so macht kann man aber nicht wiederherstellen, da btrfs es ja eben grade für /home als Zugriffsschutz sperrt. Man darf die Partition nicht als /home mounten!
Also andere Partition wegen Snapper, aber nicht als /home wegen btrfs Zugriffsschutz!
Gilt natürlich nur für Krauter ohne mitlaufendes Backup.
Ich hatte die ganz Fummelei (seit 1995!) statt und habe am vergangenen Schwarzen Freitag die einfachste aller Lösungen implementiert:
**erlangen:~ #** fdisk -l /dev/nvme0n1
**Disk /dev/nvme0n1: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors**
Disk model: Samsung SSD 970 EVO Plus 2TB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: F5B232D0-7A67-461D-8E7D-B86A5B4C6C10
**Device **** Start**** End**** Sectors**** Size****Type**
/dev/nvme0n1p1 2048 1050623 1048576 512M EFI System
/dev/nvme0n1p2 1050624 3907029134 3905978511 1.8T Linux filesystem
**erlangen:~ #**
Wer etwas anderes will hat mein Vorgehen noch nicht ausprobiert. Siehe: https://forums.opensuse.org/showthread.php/541321-Upgrading-the-Hardware?p=3086058#post3086058
Nebenbei bemerkt: Ich habe mein Vorgehen ganz detailliert aufgeschrieben, weil mir viele Leute erzählen, dass es nicht praktikabel ist. Siehe auch https://doc.opensuse.org/documentation/leap/reference/html/book-reference/cha-snapper.html#sec-snapper-homedirs
[QUOTE=karlmistelberger;3113206]Ich hatte die ganz Fummelei (seit 1995!) statt und habe am vergangenen Schwarzen Freitag die einfachste aller Lösungen implementiert:
? da wird dann /home auch noch in snapper eingebunden, also gehen Dateien bei rollback potentiell verloren?
Aber wäre sowieso ein anderes Thema, ich wollte doch ein Verzeichnis ausserhalb des /home Bereich, genau im Gegenteil, aus Snapper rausbekommen, was ja scheinbar nur mit neuer, eigener Partition geht.
Ich verstehe dich nicht. /home hat gar nichts mite Btrfs zu tun. Es ist ein xfs oder ext4 Dateisystem und natürlich als /home gemounted, sonst wäre es nichjt das /home Dateisystem.
Und für verlorene Dateien gibt as Backups. Btrfs Snapshots sind kein Erzatz Backups.
[QUOTE=hcvv;3113230]Ich verstehe dich nicht. /home hat gar nichts mite Btrfs zu tun. Es ist ein xfs…
ja wenn es xfs oder ext4 ist gibt es sozusagen nicht das Problem, allerdings ist dort die Dateiwiederherstellung immer schlechter, jedenfalls bei xfs. bei btrfs ist sie perfekt, außer im /home bereich, den schützt btrfs vor zugriffen, damit auch Wiederherstellung.
Und dein Super backup tip stimmt nur für alle die dauerläufer/mitlaufende Backups haben, nicht wenn man nur 1x pro Tag ein Backup macht.
Wiederherstellung im Sinne von Datenrettung, eh das auchnoch doof verstanden wird.
Und mit Perfekt meine ich bei Verwendung mit photorec, bzw. wenn einem photorec reicht.
Nein, / und /home sind verschieden:
**erlangen:~ #** btrfs subvolume show /
**@/.snapshots/1/snapshot **
Name: snapshot
UUID: 579f5de4-d385-d64b-a3b6-a6a09aca3fc6
Parent UUID: -
Received UUID: -
Creation time: 2021-11-24 21:33:32 +0100
Subvolume ID: 266
Generation: 130214
Gen at creation: 30
Parent ID: 265
Top level ID: 265
Flags: -
Send transid: 0
Send time: 2021-11-24 21:33:32 +0100
Receive transid: 0
Receive time: -
Snapshot(s):
@/.snapshots/272/snapshot
@/.snapshots/273/snapshot
@/.snapshots/276/snapshot
@/.snapshots/277/snapshot
@/.snapshots/278/snapshot
@/.snapshots/279/snapshot
@/.snapshots/288/snapshot
@/.snapshots/289/snapshot
@/.snapshots/292/snapshot
@/.snapshots/293/snapshot
@/.snapshots/296/snapshot
@/.snapshots/297/snapshot
@/.snapshots/298/snapshot
@/.snapshots/299/snapshot
@/.snapshots/300/snapshot
@/.snapshots/301/snapshot
@/.snapshots/302/snapshot
@/.snapshots/303/snapshot
@/.snapshots/304/snapshot
@/.snapshots/305/snapshot
@/.snapshots/306/snapshot
@/.snapshots/307/snapshot
@/.snapshots/308/snapshot
@/.snapshots/309/snapshot
@/.snapshots/310/snapshot
@/.snapshots/311/snapshot
@/.snapshots/312/snapshot
@/.snapshots/313/snapshot
@/.snapshots/314/snapshot
@/.snapshots/315/snapshot
**erlangen:~ #** btrfs subvolume show /home
**@/home **
Name: home
UUID: 63085f28-85ec-0246-a40d-cf878e0fe83a
Parent UUID: -
Received UUID: -
Creation time: 2021-11-24 21:33:32 +0100
Subvolume ID: 262
Generation: 130216
Gen at creation: 23
Parent ID: 256
Top level ID: 256
Flags: -
Send transid: 0
Send time: 2021-11-24 21:33:32 +0100
Receive transid: 0
Receive time: -
Snapshot(s):
**erlangen:~ #**
Snapshots in @/ und @/home sind voneinander vollständig unabhängig. In meinem @/home sind sie derzeit nicht eingerichtet.
Hi Alops,
ich habe nicht alles hier im Detail gelesen. Üblicherweise gibt es an den Hilfestellungen unserer Freunde hier im Forum nicht viel zu ergänzen oder kritisieren - ich würde mir das auch nie anmaßen. Ich hätte nur eine Anmerkung zum grundsätzlichen Verständnis:
BTRFS mit Snapshots unterstützt “rollback”. Das heißt in erster Linie ein Betriebssystem auf einen bestimmten Punkt zurückzustellen, wenn etwas schiefgegangen ist. Es kann ein Problem bei einem Update, einem Upgrade, einer misslungenen Softwareinstallation oder was auch immer gewesen sein. Man “rollt” das System zurück zu einem definierten Punkt. Idealerweise hat man sich den sogar vor einer größeren Operation notiert. Das macht es leichter.
Das hieße aber auch, dass /home/ **zurückgesetzt **würde, wenn man einen “zypper rollback …” ausführt. All Deine Daten in /home/… , die jünger sind als der Rücksetzpunkt wären verloren. Das wäre weder im Sinne der Entwickler von BTRFS noch im Sinne des Users.
Ich muss zugeben, ich habe mich mit den detaillierten Optionen zur Verhinderung des Problems innerhalb btrfs nicht auseinandergesetzt. Ich folge der Empfehlung, die Henk schon gegeben hat: /home/ auf eine separate Partition und in ein separates Dateisystem packen.
Have a lot of fun!
kasi
also kasi du hast garnichts gelesen und logiosch darf und ist /home nicht im rollback/snapper.
Und wenn ich / einbaue ist doch nichts ausgeschlossen wie ich will. Ich will ein bestimmtes Verzeichnis ausschliessen aus snapper.
Und das geht nicht, Thema längst geklärt, neue Partition nötig und die ohne /home da sonst btrfs eine Dateirettung blockiert.
Das ist korrekt. Aus diesem Grund gibt es bei snapper Konfigurationen:
**erlangen:~ #** snapper list-configs
Config | Subvolume
------------+-------------
home_tester | /home/tester
root | /
**erlangen:~ #**
Ein Rollback in der Konfiguration root hat keinen Einfluss auf Subvolume /home/tester und umgekehrt beeinflusst die Konfiguration home_tester aussschließlich Subvolume /home/tester.
**erlangen:~ #** snapper -c home_tester list
# | Type | Pre # | Date | User | Cleanup | Description | Userdata
---+--------+-------+--------------------------+------+----------+-------------+---------
0 | single | | | root | | current |
1 | single | | Wed Mar 9 04:41:32 2022 | root | timeline | timeline |
2 | single | | Wed Mar 9 05:00:08 2022 | root | timeline | timeline |
**erlangen:~ #**
**erlangen:~ #** snapper -c root list
# | Type | Pre # | Date | User | Cleanup | Description | Userdata
-----+--------+-------+--------------------------+------+---------+-----------------------+--------------
0 | single | | | root | | current |
1* | single | | Wed Nov 24 21:33:32 2021 | root | | first root filesystem |
272 | pre | | Sat Feb 26 04:13:45 2022 | root | number | zypp(zypper) | important=yes
273 | post | 272 | Sat Feb 26 04:15:15 2022 | root | number | | important=yes
276 | pre | | Mon Feb 28 03:26:32 2022 | root | number | zypp(zypper) | important=yes
277 | post | 276 | Mon Feb 28 03:28:04 2022 | root | number | | important=yes
278 | pre | | Mon Feb 28 03:29:08 2022 | root | number | zypp(zypper) | important=yes
279 | post | 278 | Mon Feb 28 03:29:10 2022 | root | number | | important=yes
288 | pre | | Wed Mar 2 21:53:28 2022 | root | number | zypp(zypper) | important=yes
289 | post | 288 | Wed Mar 2 21:57:45 2022 | root | number | | important=yes
292 | pre | | Thu Mar 3 19:14:59 2022 | root | number | zypp(zypper) | important=yes
293 | post | 292 | Thu Mar 3 19:15:46 2022 | root | number | | important=yes
296 | pre | | Sat Mar 5 11:25:08 2022 | root | number | zypp(zypper) | important=no
297 | post | 296 | Sat Mar 5 11:25:20 2022 | root | number | | important=no
298 | pre | | Sat Mar 5 13:03:38 2022 | root | number | zypp(zypper) | important=no
299 | post | 298 | Sat Mar 5 13:03:41 2022 | root | number | | important=no
300 | pre | | Sun Mar 6 00:08:08 2022 | root | number | zypp(zypper) | important=no
301 | post | 300 | Sun Mar 6 00:10:44 2022 | root | number | | important=no
302 | pre | | Sun Mar 6 00:20:23 2022 | root | number | zypp(zypper) | important=no
303 | post | 302 | Sun Mar 6 00:20:31 2022 | root | number | | important=no
304 | pre | | Sun Mar 6 12:26:13 2022 | root | number | zypp(zypper) | important=no
305 | post | 304 | Sun Mar 6 12:26:17 2022 | root | number | | important=no
306 | pre | | Mon Mar 7 02:14:34 2022 | root | number | zypp(zypper) | important=no
307 | post | 306 | Mon Mar 7 02:14:38 2022 | root | number | | important=no
308 | pre | | Mon Mar 7 02:14:44 2022 | root | number | zypp(zypper) | important=no
309 | post | 308 | Mon Mar 7 02:17:25 2022 | root | number | | important=no
310 | pre | | Mon Mar 7 11:16:06 2022 | root | number | zypp(zypper) | important=no
311 | post | 310 | Mon Mar 7 11:16:18 2022 | root | number | | important=no
312 | pre | | Tue Mar 8 05:02:07 2022 | root | number | zypp(zypper) | important=no
313 | post | 312 | Tue Mar 8 05:02:16 2022 | root | number | | important=no
314 | pre | | Tue Mar 8 11:30:59 2022 | root | number | zypp(zypper) | important=no
315 | post | 314 | Tue Mar 8 11:31:04 2022 | root | number | | important=no
316 | pre | | Tue Mar 8 21:58:48 2022 | root | number | zypp(zypper) | important=no
317 | post | 316 | Tue Mar 8 21:58:56 2022 | root | number | | important=no
318 | pre | | Wed Mar 9 03:28:52 2022 | root | number | yast users |
319 | post | 318 | Wed Mar 9 03:29:49 2022 | root | number | |
320 | pre | | Wed Mar 9 03:37:22 2022 | root | number | yast users |
321 | post | 320 | Wed Mar 9 03:37:41 2022 | root | number | |
**erlangen:~ #**
Details zu snapper gibt es hier: System recovery and snapshot management with Snapper, insbesondere Abschnitte 3.4 Enabling Snapper in user home directories und 3.5.1.2 Using Snapper as regular user
Nun ja, ein bisschen schon, und das hier hat mich etwas zweifeln lassen:
Irgendein sicher für professionelle Nutzer nützlicher Schutz, insbesondere weil die mitlaufende Backups haben und keine Dateiwiederherstellung benötigen.
Aber dann weißt Du ja Bescheid.
Nur zur Sicherheit für andere, die hier nachlesen: Backup der eigenen Daten - wo auch immer sie liegen - ist unerlässlich, zumindest, wenn einem diese Daten wichtig sind. Snapshots sind kein sicherer Ersatz für Backups.
Das sind aber echte Dauerbackups und nicht welche die nur 1x pro Tag laufen, wie bei dir und mir. Schon braucht man Datenrettung, was btrfs für Subvolume /home blockiert.
Wenn Festplatte defekt, kein Backup mehr…
Daher:
Schnappschüsse sind kein Backup, backups werden auf anderen Datenträgern gespeichert.
Meine rede. Richtige Unternehmen haben mitlaufende Dauerbackups, zb. auf Streamern und überhaupt gesonderten Kisten. Weshalb kein Bedarf an Datenrettung besteht und damit der Zugriffsschutz für /home bei btrfs gewollt ist.
Böllerbuden und Krauter machen aber nur irgendwann ein Backup und brauchen Datenrettung, bei /home mit btrfs nicht möglich. Obwohl sich eben außerhalb von /home grade bei btrfs die Daten mit photorec am besten wiederherstellen lassen. Eigentlich klappt es sogar so richtig nur bei btrfs und zugegebenermassen ntfs.
Wenn ein Hardwaredefekt auftritt (z.B. Beschädigung der Plattenoberfläche) helfen weder photorec, noch btrfs oder ntfs, sondern nur eine intakte Kopie auf einem zweiten Medium (das idealerweise mit Hilfe eines unabhängigen Kontrollers erstellt wurde).
Viele Grüße
susejunky
Backups herkömmlicher Art leiden unter dem klassischem Dilemma:https://recoverit.wondershare.de/data-backup/full-backup-vs-differential-backup-vs-incremental-backup.html Schnappschüsse unter btrfs ermöglichen es, inkrementelle Backups durchzuführen und deren Nachteile zu vermeiden. Ein Schnappschuss auf einem Backup-Medium stellt nämlich einen vollständigen Backup dar: https://docs.oracle.com/cd/E37670_01/E37355/html/ol_srbackup_btrfs.html