Difference between revisions of "Btrfs"

added warning out of space
m (kleine korrekturen)
(added warning out of space)
(2 intermediate revisions by the same user not shown)
Line 81: Line 81:
All subvolumes share the space of the Btrfs volume. You may create subvolumes at will. (You may think of subvolumes as sort of "dynamic partitions" inside a Btrfs volume)
All subvolumes share the space of the Btrfs volume. You may create subvolumes at will. (You may think of subvolumes as sort of "dynamic partitions" inside a Btrfs volume)


When making snapshots (or send/receive) every subvolume will be handled separately. For example when you have 2 subvolumes(@, @home), and make a snapshot of one of them(@), this snapshot will contain every bit of data of all fines in this subvolume(@), but none of the data from the other subvolume(@home). So if you make a few subvolumes, you are able to '''follow different strategies for snapshots''' of them. And you can '''restore''' each of them '''separately'''.
When making snapshots (or send/receive) every subvolume will be handled separately. For example when you have 2 subvolumes(@, @home), and make a snapshot of one of them(@), this snapshot will contain every bit of data of all files in this subvolume(@), but none of the data from the other subvolume(@home). So if you make a few subvolumes, you are able to '''follow different strategies for snapshots''' of them. And you can '''restore''' each of them '''separately'''.


By convention the names of subvolumes start with '''@ (@home, @snapshots''' ...).  
By convention the names of subvolumes start with '''@ (@home, @snapshots''' ...).  
Line 101: Line 101:


=== subvolume '''@home''' ===
=== subvolume '''@home''' ===
This is the subvolume where all '''user data''' ist stored. When you rollback your "@", this will not change at all. You may take snapshots of /home at a different rate and for different reasons. While snapshots of "@"  are good for rollback, snapshots of @homw are good for '''undeleting''' accidentally by users deleted (or overwritten) files.  
This is the subvolume where all '''user data''' ist stored. When you rollback your "@", this will not change at all. You may take snapshots of /home at a different rate and for different reasons. While snapshots of "@"  are good for rollback, snapshots of @home are good for '''undeleting''' accidentally by users deleted (or overwritten) files.  


=== subvolume '''@snapshots''', '''@home.snapshots''' ===
=== subvolume '''@snapshots''', '''@home.snapshots''' ===
Line 113: Line 113:
A snapshot is read-only. Therefore it is guaranteed not to change. In a snapshot you will find all files of the subvolume frozen in time. {{BoxWarning|Where to place snapshots|When creating snapshots you have to watch out for the volume layout in use}}
A snapshot is read-only. Therefore it is guaranteed not to change. In a snapshot you will find all files of the subvolume frozen in time. {{BoxWarning|Where to place snapshots|When creating snapshots you have to watch out for the volume layout in use}}


Taking a snapshot is '''very fast''', and '''nearly priceless'''. After the snapshot is taken, all future writes will go as in CoW usual. But none of the space occupied by files in the snapshot will be reusable. As you write more and more new files the filesystem will grow because it can not reuse the files in the snapshot. A new snapshot will freeze additional all created or modified files since the last snapshot and so on. If you don´t release(delete) any snapshot you will eventually run out of space soon(disk full)
Taking a snapshot is '''very fast''', and '''nearly priceless'''. After the snapshot is taken, all future writes will go as in CoW usual. But none of the space occupied by files in the snapshot will be reusable. As you write more and more new files the filesystem will grow because it can not reuse the files in the snapshot. A new snapshot will freeze additionaly all created or modified files since the last snapshot and so on. '''If you don´t release'''(delete) any snapshot '''you will''' eventually '''run out of space''' soon(disk full)


Deleting a snapshot does not delete any files that are actually in use by other snapshots or the subvolume they where taken from. But to free some space, Btrfs has to test for every file in the snapshot, whether it is in use, or it is not. If it is not, the space of this file/version will be freed.(This is greatly simplified) Therefore it is '''costly to remove snapshots'''. And Btrfs will do this work in the background. You may notice this, because when you delete a snapshot there will be '''no immediate gain in freed space'''. After a while you will notice that some space was freed.  
Deleting a snapshot does not delete any files that are actually in use by other snapshots or the subvolume they where taken from. To free some space, Btrfs has to test for every file in the snapshot, whether it is in use, or it is not. If it is not, the space of this file/version will be freed.(This is greatly simplified) Therefore it is '''costly to remove snapshots'''. And Btrfs will do this work in the background. You may notice this, because when you delete a snapshot there will be '''no immediate gain in freed space'''. After a while you will notice that some space was freed.


Snapshots (if regularly made) may be used for:
Snapshots (if regularly made) may be used for:
* comparing config files from different "times"
* Comparing config files from different "times"
* merging config files
* Merging config files
* recovering accidentally deleted/overwritten files
* Recovering accidentally deleted/overwritten files
* system roll back
* Rollback your system
* anchor for a backup with send/receive
* Anchor for a backup with send/receive
* basis for a seed
* Basis for a seed
* ''what do you use snapshots for ?''
* ''What do you use snapshots for ?''
 
Don´t forget to remove snapshots, or you will get in '''"out of space" -trouble soon'''. Btrfs needs some free space to manage its work. If your volume is more then 90% full you have to think(fast) what to do.
* ++++ '''Add''' some partition/device to the volume
* +++ '''Remove''' some snapshots you don't need
* + '''Delete''' some files (this does only help if they are not part of any snapshot)


Making and deleting snapshots is best done automatically:
Making and deleting snapshots is best done automatically:
Line 131: Line 136:


If you need to roll back into a snapshot you have to replace the actual subvolume by the chosen snapshot.
If you need to roll back into a snapshot you have to replace the actual subvolume by the chosen snapshot.
* Make a snapshot of the actual subvolume (for later reference)
# '''Make a snapshot''' of the actual subvolume (for later reference)
* Move the subvolume out of its actual place
# '''Delete the subvolume''' out of its actual place
* Create a new subvolume from the snapshot chosen for roll back
# '''Create a new subvolume''' out of the snapshot chosen for rollback
* Make the new subvolume the default
# Make this new subvolume the default (optional)
# '''Don't forget''' to remove the snapshot you made in a few days
 
{{BoxWarning|Don't forget to remove snapshots before you run out of space|Every time you take a snapshot you only use the "rest of the volume" for storing everything you change from this time on. At some point in time you have to release the snapshot. Don´t use your space up. Btrfs needs '''space to breath.''' Don't use more then 90% or you will get into trouble."}}


{{BoxDanger|NO Snapshots together with quotas|There are reports about massive problems when using '''quotas''' together with snapshots (snapper, timeshift)}}
{{BoxDanger|NO Snapshots together with quotas|There are reports about massive problems when using '''quotas''' together with snapshots (snapper, timeshift)}}
translator
995

edits