Snapshots of btrfs

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite












On my debian system, I am using hdds formatted with btrfs to make backups. The large volumes of data are my music and photo collections so it tends to be relatively stable and only growing.



I mount the btrfs volume in /media/backup, then I have a subdirectory backup and within that I have directories for the various sets of backup I am making. After I do the nightly backup, I make a snapshot.



DATE=$(date +"%Y%m%d_%H%M")
btrfs subvolume snapshot /media/backup /media/backup/$DATE



For the first day, this worked as expected, but the next day, the snapshot also contained the first days snapshot, the day after the snapshot contained the two first snapshots and so on..



If I have understood correctly what happens when I do a btrfs snapshot, this has no practical implications, the usage of disk space is absolutely marginal, but as it looks a bit messy, I would like to avoid it. My first idea was to do a snapshot of /media/backup/backup to avoid this, but as I tried to make a snapshot of a directory rather than a volume, that did of course not work.



Is there any way I can make a number of snapshot of the same volume and avoid having the newer snapshot also point to all the older ones?







share|improve this question




















  • I am not sure that BTRFS snapshots are a viable for backup/archive as a there should only be a few snapshots of a single volume at any one time: mail-archive.com/linux-btrfs@vger.kernel.org/msg72416.html and unix.stackexchange.com/questions/140360/…
    – StrongBad
    Feb 7 at 20:45














up vote
1
down vote

favorite












On my debian system, I am using hdds formatted with btrfs to make backups. The large volumes of data are my music and photo collections so it tends to be relatively stable and only growing.



I mount the btrfs volume in /media/backup, then I have a subdirectory backup and within that I have directories for the various sets of backup I am making. After I do the nightly backup, I make a snapshot.



DATE=$(date +"%Y%m%d_%H%M")
btrfs subvolume snapshot /media/backup /media/backup/$DATE



For the first day, this worked as expected, but the next day, the snapshot also contained the first days snapshot, the day after the snapshot contained the two first snapshots and so on..



If I have understood correctly what happens when I do a btrfs snapshot, this has no practical implications, the usage of disk space is absolutely marginal, but as it looks a bit messy, I would like to avoid it. My first idea was to do a snapshot of /media/backup/backup to avoid this, but as I tried to make a snapshot of a directory rather than a volume, that did of course not work.



Is there any way I can make a number of snapshot of the same volume and avoid having the newer snapshot also point to all the older ones?







share|improve this question




















  • I am not sure that BTRFS snapshots are a viable for backup/archive as a there should only be a few snapshots of a single volume at any one time: mail-archive.com/linux-btrfs@vger.kernel.org/msg72416.html and unix.stackexchange.com/questions/140360/…
    – StrongBad
    Feb 7 at 20:45












up vote
1
down vote

favorite









up vote
1
down vote

favorite











On my debian system, I am using hdds formatted with btrfs to make backups. The large volumes of data are my music and photo collections so it tends to be relatively stable and only growing.



I mount the btrfs volume in /media/backup, then I have a subdirectory backup and within that I have directories for the various sets of backup I am making. After I do the nightly backup, I make a snapshot.



DATE=$(date +"%Y%m%d_%H%M")
btrfs subvolume snapshot /media/backup /media/backup/$DATE



For the first day, this worked as expected, but the next day, the snapshot also contained the first days snapshot, the day after the snapshot contained the two first snapshots and so on..



If I have understood correctly what happens when I do a btrfs snapshot, this has no practical implications, the usage of disk space is absolutely marginal, but as it looks a bit messy, I would like to avoid it. My first idea was to do a snapshot of /media/backup/backup to avoid this, but as I tried to make a snapshot of a directory rather than a volume, that did of course not work.



Is there any way I can make a number of snapshot of the same volume and avoid having the newer snapshot also point to all the older ones?







share|improve this question












On my debian system, I am using hdds formatted with btrfs to make backups. The large volumes of data are my music and photo collections so it tends to be relatively stable and only growing.



I mount the btrfs volume in /media/backup, then I have a subdirectory backup and within that I have directories for the various sets of backup I am making. After I do the nightly backup, I make a snapshot.



DATE=$(date +"%Y%m%d_%H%M")
btrfs subvolume snapshot /media/backup /media/backup/$DATE



For the first day, this worked as expected, but the next day, the snapshot also contained the first days snapshot, the day after the snapshot contained the two first snapshots and so on..



If I have understood correctly what happens when I do a btrfs snapshot, this has no practical implications, the usage of disk space is absolutely marginal, but as it looks a bit messy, I would like to avoid it. My first idea was to do a snapshot of /media/backup/backup to avoid this, but as I tried to make a snapshot of a directory rather than a volume, that did of course not work.



Is there any way I can make a number of snapshot of the same volume and avoid having the newer snapshot also point to all the older ones?









share|improve this question











share|improve this question




share|improve this question










asked Feb 7 at 19:26









MortenSickel

7741916




7741916











  • I am not sure that BTRFS snapshots are a viable for backup/archive as a there should only be a few snapshots of a single volume at any one time: mail-archive.com/linux-btrfs@vger.kernel.org/msg72416.html and unix.stackexchange.com/questions/140360/…
    – StrongBad
    Feb 7 at 20:45
















  • I am not sure that BTRFS snapshots are a viable for backup/archive as a there should only be a few snapshots of a single volume at any one time: mail-archive.com/linux-btrfs@vger.kernel.org/msg72416.html and unix.stackexchange.com/questions/140360/…
    – StrongBad
    Feb 7 at 20:45















I am not sure that BTRFS snapshots are a viable for backup/archive as a there should only be a few snapshots of a single volume at any one time: mail-archive.com/linux-btrfs@vger.kernel.org/msg72416.html and unix.stackexchange.com/questions/140360/…
– StrongBad
Feb 7 at 20:45




I am not sure that BTRFS snapshots are a viable for backup/archive as a there should only be a few snapshots of a single volume at any one time: mail-archive.com/linux-btrfs@vger.kernel.org/msg72416.html and unix.stackexchange.com/questions/140360/…
– StrongBad
Feb 7 at 20:45










1 Answer
1






active

oldest

votes

















up vote
2
down vote



accepted










First off, if you look at the most recent snapshot, you will notice that the directories from the previous snapshot don't contain any actual data inside the new snapshot, so it's not just marginal disk usage, it's zero extra.



Now, as to avoiding them, the only way to do so is to store your snapshots somewhere that isn't covered by the snapshot process. For this, you essentially have two options:




  1. Create a dedicated subvolume for your snapshots inside the subvolume you're snapshotting. Snapshots stop at subvolume boundaries (which is the reason that they won't store copies of existing snapshots), so you won't have any of them in your snapshots, just an empty directory for the snapshots subvolume. This is probably the easiest option to adopt right now, as it just requires creating the subvolume with btrfs subvolume create and pointing the snapshot creation script there for the location to store the snapshots. For what it's worth, .snapshots seems to be a de-facto standard name for this approach. After a few days of using this your directory tree would look roughly like this:



    /media/backups
    /media/backups/.snapshots
    /media/backups/.snapshots/20180207_1342
    /media/backups/.snapshots/20180209_0415
    /media/backups/.snapshots/20180312_1754


    All your non-snapshot data is in /media/backups, and all your individual snapshots are stored under /media/backups/.snapshots. Each snapshot will have an empty .snapshots directory in it.




  2. Instead of using the root subvolume of the BTRFS volume, put all your actual data in it's own subvolume, and snapshot that while placing the snapshots outside of it. This approach is not as easy to convert to, and will likely require you to update more than just your snapshot command, but also makes it easier to roll-back an entire snapshot all at once. After a few snapshots using this method, your directory tree would look something like this:



    /media/backups/current
    /media/backups/20180207_1342
    /media/backups/20180209_0415
    /media/backups/20180312_1754


    All your data is stored in /media/backups/current (which needs to be a BTRFS subvolume just like .snapshots does with the first method), and your snapshots sit alongside it under /media/backups. You can easily restore an entire snapshot by simply deleting the current subvolume and creating a writable snapshot called current of the snapshot you want to restore.



Now, there are two other observations I would like to make regarding what you've said that aren't directly part of your question:



  1. The command you listed will create writable snapshots. This is almost certainly not what you want if your purpose here is to maintain archival copies of your collection, so I would suggest adding -r to the options to make the snapshots read-only. In the event you need to modify one (for example, if you need to completely purge a file from the collection), you can still use the btrfs property set command to toggle the read-only flag on the snapshot.

  2. While not technically a significant issue, your timestamp format is somewhat unconventional, and as such may cause you problems if you try to deal with these snapshots with another tool or might confuse other people if you need to share this data. Given that, I would suggest using `'%FT%T', which will give you an ISO 8601 timestamp that should be parsable by all software and immediately recognizable to most people, while still providing sensible lexical sorting of the snapshots.





share|improve this answer




















  • Absolutely right with the writeable snapshots - I thought ro was the default. ...
    – MortenSickel
    Feb 8 at 7:38










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);








 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f422635%2fsnapshots-of-btrfs%23new-answer', 'question_page');

);

Post as a guest






























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
2
down vote



accepted










First off, if you look at the most recent snapshot, you will notice that the directories from the previous snapshot don't contain any actual data inside the new snapshot, so it's not just marginal disk usage, it's zero extra.



Now, as to avoiding them, the only way to do so is to store your snapshots somewhere that isn't covered by the snapshot process. For this, you essentially have two options:




  1. Create a dedicated subvolume for your snapshots inside the subvolume you're snapshotting. Snapshots stop at subvolume boundaries (which is the reason that they won't store copies of existing snapshots), so you won't have any of them in your snapshots, just an empty directory for the snapshots subvolume. This is probably the easiest option to adopt right now, as it just requires creating the subvolume with btrfs subvolume create and pointing the snapshot creation script there for the location to store the snapshots. For what it's worth, .snapshots seems to be a de-facto standard name for this approach. After a few days of using this your directory tree would look roughly like this:



    /media/backups
    /media/backups/.snapshots
    /media/backups/.snapshots/20180207_1342
    /media/backups/.snapshots/20180209_0415
    /media/backups/.snapshots/20180312_1754


    All your non-snapshot data is in /media/backups, and all your individual snapshots are stored under /media/backups/.snapshots. Each snapshot will have an empty .snapshots directory in it.




  2. Instead of using the root subvolume of the BTRFS volume, put all your actual data in it's own subvolume, and snapshot that while placing the snapshots outside of it. This approach is not as easy to convert to, and will likely require you to update more than just your snapshot command, but also makes it easier to roll-back an entire snapshot all at once. After a few snapshots using this method, your directory tree would look something like this:



    /media/backups/current
    /media/backups/20180207_1342
    /media/backups/20180209_0415
    /media/backups/20180312_1754


    All your data is stored in /media/backups/current (which needs to be a BTRFS subvolume just like .snapshots does with the first method), and your snapshots sit alongside it under /media/backups. You can easily restore an entire snapshot by simply deleting the current subvolume and creating a writable snapshot called current of the snapshot you want to restore.



Now, there are two other observations I would like to make regarding what you've said that aren't directly part of your question:



  1. The command you listed will create writable snapshots. This is almost certainly not what you want if your purpose here is to maintain archival copies of your collection, so I would suggest adding -r to the options to make the snapshots read-only. In the event you need to modify one (for example, if you need to completely purge a file from the collection), you can still use the btrfs property set command to toggle the read-only flag on the snapshot.

  2. While not technically a significant issue, your timestamp format is somewhat unconventional, and as such may cause you problems if you try to deal with these snapshots with another tool or might confuse other people if you need to share this data. Given that, I would suggest using `'%FT%T', which will give you an ISO 8601 timestamp that should be parsable by all software and immediately recognizable to most people, while still providing sensible lexical sorting of the snapshots.





share|improve this answer




















  • Absolutely right with the writeable snapshots - I thought ro was the default. ...
    – MortenSickel
    Feb 8 at 7:38














up vote
2
down vote



accepted










First off, if you look at the most recent snapshot, you will notice that the directories from the previous snapshot don't contain any actual data inside the new snapshot, so it's not just marginal disk usage, it's zero extra.



Now, as to avoiding them, the only way to do so is to store your snapshots somewhere that isn't covered by the snapshot process. For this, you essentially have two options:




  1. Create a dedicated subvolume for your snapshots inside the subvolume you're snapshotting. Snapshots stop at subvolume boundaries (which is the reason that they won't store copies of existing snapshots), so you won't have any of them in your snapshots, just an empty directory for the snapshots subvolume. This is probably the easiest option to adopt right now, as it just requires creating the subvolume with btrfs subvolume create and pointing the snapshot creation script there for the location to store the snapshots. For what it's worth, .snapshots seems to be a de-facto standard name for this approach. After a few days of using this your directory tree would look roughly like this:



    /media/backups
    /media/backups/.snapshots
    /media/backups/.snapshots/20180207_1342
    /media/backups/.snapshots/20180209_0415
    /media/backups/.snapshots/20180312_1754


    All your non-snapshot data is in /media/backups, and all your individual snapshots are stored under /media/backups/.snapshots. Each snapshot will have an empty .snapshots directory in it.




  2. Instead of using the root subvolume of the BTRFS volume, put all your actual data in it's own subvolume, and snapshot that while placing the snapshots outside of it. This approach is not as easy to convert to, and will likely require you to update more than just your snapshot command, but also makes it easier to roll-back an entire snapshot all at once. After a few snapshots using this method, your directory tree would look something like this:



    /media/backups/current
    /media/backups/20180207_1342
    /media/backups/20180209_0415
    /media/backups/20180312_1754


    All your data is stored in /media/backups/current (which needs to be a BTRFS subvolume just like .snapshots does with the first method), and your snapshots sit alongside it under /media/backups. You can easily restore an entire snapshot by simply deleting the current subvolume and creating a writable snapshot called current of the snapshot you want to restore.



Now, there are two other observations I would like to make regarding what you've said that aren't directly part of your question:



  1. The command you listed will create writable snapshots. This is almost certainly not what you want if your purpose here is to maintain archival copies of your collection, so I would suggest adding -r to the options to make the snapshots read-only. In the event you need to modify one (for example, if you need to completely purge a file from the collection), you can still use the btrfs property set command to toggle the read-only flag on the snapshot.

  2. While not technically a significant issue, your timestamp format is somewhat unconventional, and as such may cause you problems if you try to deal with these snapshots with another tool or might confuse other people if you need to share this data. Given that, I would suggest using `'%FT%T', which will give you an ISO 8601 timestamp that should be parsable by all software and immediately recognizable to most people, while still providing sensible lexical sorting of the snapshots.





share|improve this answer




















  • Absolutely right with the writeable snapshots - I thought ro was the default. ...
    – MortenSickel
    Feb 8 at 7:38












up vote
2
down vote



accepted







up vote
2
down vote



accepted






First off, if you look at the most recent snapshot, you will notice that the directories from the previous snapshot don't contain any actual data inside the new snapshot, so it's not just marginal disk usage, it's zero extra.



Now, as to avoiding them, the only way to do so is to store your snapshots somewhere that isn't covered by the snapshot process. For this, you essentially have two options:




  1. Create a dedicated subvolume for your snapshots inside the subvolume you're snapshotting. Snapshots stop at subvolume boundaries (which is the reason that they won't store copies of existing snapshots), so you won't have any of them in your snapshots, just an empty directory for the snapshots subvolume. This is probably the easiest option to adopt right now, as it just requires creating the subvolume with btrfs subvolume create and pointing the snapshot creation script there for the location to store the snapshots. For what it's worth, .snapshots seems to be a de-facto standard name for this approach. After a few days of using this your directory tree would look roughly like this:



    /media/backups
    /media/backups/.snapshots
    /media/backups/.snapshots/20180207_1342
    /media/backups/.snapshots/20180209_0415
    /media/backups/.snapshots/20180312_1754


    All your non-snapshot data is in /media/backups, and all your individual snapshots are stored under /media/backups/.snapshots. Each snapshot will have an empty .snapshots directory in it.




  2. Instead of using the root subvolume of the BTRFS volume, put all your actual data in it's own subvolume, and snapshot that while placing the snapshots outside of it. This approach is not as easy to convert to, and will likely require you to update more than just your snapshot command, but also makes it easier to roll-back an entire snapshot all at once. After a few snapshots using this method, your directory tree would look something like this:



    /media/backups/current
    /media/backups/20180207_1342
    /media/backups/20180209_0415
    /media/backups/20180312_1754


    All your data is stored in /media/backups/current (which needs to be a BTRFS subvolume just like .snapshots does with the first method), and your snapshots sit alongside it under /media/backups. You can easily restore an entire snapshot by simply deleting the current subvolume and creating a writable snapshot called current of the snapshot you want to restore.



Now, there are two other observations I would like to make regarding what you've said that aren't directly part of your question:



  1. The command you listed will create writable snapshots. This is almost certainly not what you want if your purpose here is to maintain archival copies of your collection, so I would suggest adding -r to the options to make the snapshots read-only. In the event you need to modify one (for example, if you need to completely purge a file from the collection), you can still use the btrfs property set command to toggle the read-only flag on the snapshot.

  2. While not technically a significant issue, your timestamp format is somewhat unconventional, and as such may cause you problems if you try to deal with these snapshots with another tool or might confuse other people if you need to share this data. Given that, I would suggest using `'%FT%T', which will give you an ISO 8601 timestamp that should be parsable by all software and immediately recognizable to most people, while still providing sensible lexical sorting of the snapshots.





share|improve this answer












First off, if you look at the most recent snapshot, you will notice that the directories from the previous snapshot don't contain any actual data inside the new snapshot, so it's not just marginal disk usage, it's zero extra.



Now, as to avoiding them, the only way to do so is to store your snapshots somewhere that isn't covered by the snapshot process. For this, you essentially have two options:




  1. Create a dedicated subvolume for your snapshots inside the subvolume you're snapshotting. Snapshots stop at subvolume boundaries (which is the reason that they won't store copies of existing snapshots), so you won't have any of them in your snapshots, just an empty directory for the snapshots subvolume. This is probably the easiest option to adopt right now, as it just requires creating the subvolume with btrfs subvolume create and pointing the snapshot creation script there for the location to store the snapshots. For what it's worth, .snapshots seems to be a de-facto standard name for this approach. After a few days of using this your directory tree would look roughly like this:



    /media/backups
    /media/backups/.snapshots
    /media/backups/.snapshots/20180207_1342
    /media/backups/.snapshots/20180209_0415
    /media/backups/.snapshots/20180312_1754


    All your non-snapshot data is in /media/backups, and all your individual snapshots are stored under /media/backups/.snapshots. Each snapshot will have an empty .snapshots directory in it.




  2. Instead of using the root subvolume of the BTRFS volume, put all your actual data in it's own subvolume, and snapshot that while placing the snapshots outside of it. This approach is not as easy to convert to, and will likely require you to update more than just your snapshot command, but also makes it easier to roll-back an entire snapshot all at once. After a few snapshots using this method, your directory tree would look something like this:



    /media/backups/current
    /media/backups/20180207_1342
    /media/backups/20180209_0415
    /media/backups/20180312_1754


    All your data is stored in /media/backups/current (which needs to be a BTRFS subvolume just like .snapshots does with the first method), and your snapshots sit alongside it under /media/backups. You can easily restore an entire snapshot by simply deleting the current subvolume and creating a writable snapshot called current of the snapshot you want to restore.



Now, there are two other observations I would like to make regarding what you've said that aren't directly part of your question:



  1. The command you listed will create writable snapshots. This is almost certainly not what you want if your purpose here is to maintain archival copies of your collection, so I would suggest adding -r to the options to make the snapshots read-only. In the event you need to modify one (for example, if you need to completely purge a file from the collection), you can still use the btrfs property set command to toggle the read-only flag on the snapshot.

  2. While not technically a significant issue, your timestamp format is somewhat unconventional, and as such may cause you problems if you try to deal with these snapshots with another tool or might confuse other people if you need to share this data. Given that, I would suggest using `'%FT%T', which will give you an ISO 8601 timestamp that should be parsable by all software and immediately recognizable to most people, while still providing sensible lexical sorting of the snapshots.






share|improve this answer












share|improve this answer



share|improve this answer










answered Feb 7 at 20:22









Austin Hemmelgarn

5,1341915




5,1341915











  • Absolutely right with the writeable snapshots - I thought ro was the default. ...
    – MortenSickel
    Feb 8 at 7:38
















  • Absolutely right with the writeable snapshots - I thought ro was the default. ...
    – MortenSickel
    Feb 8 at 7:38















Absolutely right with the writeable snapshots - I thought ro was the default. ...
– MortenSickel
Feb 8 at 7:38




Absolutely right with the writeable snapshots - I thought ro was the default. ...
– MortenSickel
Feb 8 at 7:38












 

draft saved


draft discarded


























 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f422635%2fsnapshots-of-btrfs%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay