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:Vollständige, differenzielle und inkrementelle Backups | Recoverit 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: Oracle Linux 6 - Documentation
Backups sollten regelmässig ab einem virenfreien Bootmedium erstellt werden. Moderne USB-Wechselmedien sind so schnell, dass inkrementelle und differenzielle Backups überflüssig sind. Also in Privathaushalten immer brav und regelmässig Vollbackups auf USB-Wechselmedien erstellen. Siehe dazu:
Snapshots sind nützlich um rasch und unkompliziert versehentlich modifzierte oder gelöschte Dateien und Verzeichnisse wiederherzustellen. Für Snapshots sind unter Linux kein Btrfs (SUSE) oder ZFS (Ubuntu) erforderlich. Dank XFS Reflink kann man auch mit einer XFS-Partition eine den Snapshots entsprechende Funktionalität realisieren. Siehe dazu:
https://forums.opensuse.org/showthread.php/548533-btrfs-home-verzeichnis-sichtbar-machen-bei-boot-mit-anderem-betriebssystem
Es sollte auch klar sein, dass:
a) persönliche Daten auf eine eigenständige home-Partition gehören (üblich: /home).
b) Daten von Serverdiensten+Datenbanken auf eigenständige Datenpartitionen gehören (z.B. /opt)
dann enthält die root-Partition nur noch das Betriebssystem und die Programme. Was die root-Partition relativ klein hält (< 20 GB). Füllt ein Benutzer oder eine Benutzerin die home-Partition (dank fehlender “Disk Quota”), sollte das Betriebssytem nicht durch fehlenden Speicherplatz in seiner Funktionalität beeinträchtigt sein. Häufig wird von erfahrenen Administratoren für home- und Daten-Partitionen in der /etc/fstab spezielle Mount-Optionen wie noexec, nosuid eingesetzt, was die Sicherheit erhöhen (kann). Diese Mount-Optionen wären bei der root-Partition fehl am Platz.
Für einen möglichst stabilen Rechnerbetrieb sind einige Punkte zu beachten:
c) Nach Möglichkeit Einsatz von einer unterstützten** LTS-LInuxdistributionen** (> 5 Jahre Sicherheitsupdates): Red Hat Enterprise Linux und deren kostenlose Ablegern AlmaLinux und Rocky Linux, SUSE Linux Enterprise, sowie Ubuntu Server. Wer hat schon die Nerven und die Zeit sich freiwillig mit “Rolling Release”-Betriebssystemen wie zum Beispiel: OpenSUSE Tumbleweed, Microsoft Windows 10, Arch Linux, Gentoo Linux und FreeBSD rumzuärgern? Ob man OpenSUSE Leap ab Version 15 als kostenlosen Ableger von SUSE Linux Enterprise erachtet oder nicht, darf jeder Leser und Leserin für sich selber entscheiden. Je weniger Zeilen Programmcode geändert wird, desto unwahrscheinlicher ist das Auftreten von Softwareprobleme verursacht durch Regression.
https://en.wikipedia.org/wiki/Long-term_supportRegressionstest – Wikipedia
Angaben zu den aktuell unterstützten (Open)SUSE-Linuxdistributionen findet man unter:
https://en.opensuse.org/Lifetime
d) Nach Möglichkeit Einsatz von LTS-Softwareversionen anstelle der konventionellen Softwareversionen. Zum Beispiel Firefox ESR statt Firefox. Siehe dazu:
https://forums.opensuse.org/showthread.php/555850-Mozilla-Firefox-90-unleserliche-Inhalte?p=3066600#post3066600
Auch hier wieder: Je weniger Zeilen Programmcode geändert wird, desto unwahrscheinlicher ist das Auftreten von Softwareprobleme verursacht durch Regression.
https://de.wikipedia.org/wiki/Regressionstest
e) Alle Dateien, welche der Administrator respektive die Administratorin mit root-/Administrator-Rechte in die root-Partition einbringt oder verändert, müssen einer Versionskontrolle unterstehen. Es muss immer nachvollziehbar sein, wer, was, wann, wie auf der root-Partition modifiziert hat. Im wesentlichen sind die Konfigurationsdateien und selbst erstellten Programme und Shellskripte unter Versionskontrolle zu bringen. Selbst erstellte Konfigurationsdateien, Programme und Shellskripte kann man mit Git verwalten. Selbst sprechend sind diese Git-Repositories auf mehreren Datenträger abzulegen (=> Thema “Backup”). Alle Konfigurationsdateien und Shellskripte, die nicht bereits in einem offiziellen RPM enthalten sind, sollten auf den Linux-Rechnern per selbst erstelltem Softwarepaket verteilt und installiert werden (SUSE und RedHat: RPM; Ubuntu: DEB).
f) Minor- und Major-Upgrades gemäss:
https://en.opensuse.org/Lifetime
müssen vor der Installation auf dem Produktivsystem auf einer hardware- und softwaremässig identischen Testumgebung ausgiebig getestet werden. In der Testphase müssen auch die selbst erstellten und modifizerten Konfigurationsdateien, Programme und Shellskripte allenfalls für dieses Upgrade angepasst und getestet werden. Minor-Upgrades darf man bei RedHat und SUSE Linux Enterprise und deren kostenlosen Abkömmlinge einmal jährlich erwarten. Major-Upgrades darf man bei RedHat, SUSE Linux Enterprise, Ubuntu Server und deren kostenlosen Abkömmlinge einmal alle 5 bis 10 Jahren erwarten. Eine hardwaremässig identische Testumgebung ist ja sowieso erforderlich und sollte vorhanden sein, damit man im Fall eines Hardwaredefekts rasch die defekte Hardware ersetzen kann.
Bei Major-Upgrades empfehle ich das vollständige Löschen der Festplatte oder SSD per “Secure Erase”. Damit allenfalls vorhandene Schadsoftware (Virus) das Major-Upgrades NICHT übersteht. Mit diesem Vorgehen wird auch regelmässig das Backupverfahren und dessen Restore getestet. Beim Major-Upgrades sollte auch gleich das root-Passwort geändert werden.
Für das Einspielen von Minor- und Major-Upgrades auf Produktivsystemen muss ein Drehbuch erstellt werden. Das Drehbuch wird während dem Testen auf der Testumgebung erstellt.
g) Auf dem Produktivsystem sollten nur nicht-sicherheitsrelevante Softwareupdates installiert werden, welche vorgängig auf der Testumgebung ausgiebig getestet wurden. Sicherheitsrelevante Softwareupdates sollten rasch möglichst installiert werden. Ob man sicherheitsrelevante Softwareupdates vor der Installationsfreigabe auf der Testumgebung testen will oder nicht, ist dem Administrator überlassen. Zum Einspielen von sicherheitsrelevanter Softwareupdates unter OpenSUSE oder SUSE Linux Enterprise siehe auch (Seite 2 beachten!):
https://forums.opensuse.org/showthread.php/547458-Softwareupdates-(im-Allgemeinen)
h) Alle Modifikationen der root-Partition durch den Adminstrator sind in einem oder mehreren Logbüchern zu protokollieren. Als Logbuch erachte ich auch die Logdatei /var/log/zypp/history, welche alle durch zypper durchgeführte Softwareupdates und Softwareinstallationen protokolliert. Diese Logdatei ist am bequemsten im YAST2-Modul “Software installieren oder löschen” per Menüpunkt “Verlauf anzeigen” einsehbar.
Werden alle oben genannte Punkte strikt eingehalten, erübrigt sich aus meiner Sicht der Einsatz von Snapper.
Die Praxis ist glücklicherweise wesentlich einfacher als die tönerne Theorie. btrfs bietet die ultimative Flexibilität und Funktionalität.
Beispiel Backup von /home (sda2) auf /backup-home (sdb13):
**i3-4130:~ #** fdisk -l /dev/sda2 /dev/sdb13
**Disk /dev/sda2: 134.74 GiB, 144676225024 bytes, 282570752 sectors**
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
**Disk /dev/sdb13: 48.83 GiB, 52428800000 bytes, 102400000 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
**i3-4130:~ #**
Subvolume home auf sda2
**i3-4130:~ #** btrfs subvolume show -r 263 /
@/home
Name: home
UUID: 886ff6be-d0f6-c743-bf97-5ced16ab11b9
Parent UUID: -
Received UUID: -
Creation time: 2020-07-13 16:59:01 +0200
Subvolume ID: 263
Generation: 118935
Gen at creation: 24
Parent ID: 256
Top level ID: 256
Flags: -
Send transid: 0
Send time: 2020-07-13 16:59:01 +0200
Receive transid: 0
Receive time: -
Snapshot(s):
@/home/backup_0
@/home/backup_1
@/home/backup_2
@/home/backup_3
@/home/backup_4
@/home/backup_5
Quota group: 0/263
Limit referenced: -
Limit exclusive: -
Usage referenced: 3.88GiB
Usage exclusive: 235.20MiB
**i3-4130:~ #**
Subvolumes auf sdb13:
**i3-4130:~ #** btrfs subvolume list -t /backup-home
ID gen top level path
-- --- --------- ----
256 19 5 backup_0
258 26 5 backup_1
259 30 5 backup_2
260 35 5 backup_3
261 39 5 backup_4
262 42 5 backup_5
**i3-4130:~ #**
Backups erfordern keine zusätzliche Software sondern können ratz fatz aus dem Handgelenk gemacht werden:
**i3-4130:~ #** btrfs subvolume snapshot -r /home /home/backup_6
Create a readonly snapshot of '/home' in '/home/backup_6'
**i3-4130:~ #** btrfs send -p /home/backup_5 /home/backup_6 | btrfs receive /backup-home
At subvol /home/backup_6
At snapshot backup_6
**i3-4130:~ #**
btrfs minimiert den Aufwand. Es liefert einen vollständigen Backup zum Preis eines inkrementellen Backups.