btrfs: imaging a volume to an external file
I recently built a system with a btrfs root partition. The most compelling reason for adopting btrfs compared to ext4, in my case, was live copy-on-write snapshots, with near-zero latency. Compared to ext4, when a full system backup entailed taking down the system, mounting from a live distribution, and building a partclone image on removable media, the promise of snapshots is that the snapshot can be captured on the backup media while the system is live.
To my astonishment, no tool exists, however, that will capture the entire snapshot to a single file on external media, such that if the system is restored from that file, all applications will have the same view of the filesystem as before the crash (except that the other snapshots or subvolumes are missing).
The documentation suggests mirroring the directory tree using a tool such as rsync, or using btrfs-send/btrfs-receive to capture the incremental changes on another system. In the first case, I have always found it nearly impossible to recreate all the metadata in a file tree exactly by mirroring a file tree rather than imaging the file system, and have little optimism that a restore would be very smooth. I always find that some metadata, be it permissions, timestamps, hidden files, or so on, are not properly captured. The problem is compounded when the transfer occurs across file systems of different types. The other suggestion assumes another btrfs file system is available, which is not always the case.
Are any suggestions available for saving or restoring a volume-level image, similar to a partclone file, but representing only a select subvolume?
linux backup filesystems btrfs
asked Jan 20 at 6:26
eplepl
104
add a comment |
I recently built a system with a btrfs root partition. The most compelling reason for adopting btrfs compared to ext4, in my case, was live copy-on-write snapshots, with near-zero latency. Compared to ext4, when a full system backup entailed taking down the system, mounting from a live distribution, and building a partclone image on removable media, the promise of snapshots is that the snapshot can be captured on the backup media while the system is live.
To my astonishment, no tool exists, however, that will capture the entire snapshot to a single file on external media, such that if the system is restored from that file, all applications will have the same view of the filesystem as before the crash (except that the other snapshots or subvolumes are missing).
The documentation suggests mirroring the directory tree using a tool such as rsync, or using btrfs-send/btrfs-receive to capture the incremental changes on another system. In the first case, I have always found it nearly impossible to recreate all the metadata in a file tree exactly by mirroring a file tree rather than imaging the file system, and have little optimism that a restore would be very smooth. I always find that some metadata, be it permissions, timestamps, hidden files, or so on, are not properly captured. The problem is compounded when the transfer occurs across file systems of different types. The other suggestion assumes another btrfs file system is available, which is not always the case.
Are any suggestions available for saving or restoring a volume-level image, similar to a partclone file, but representing only a select subvolume?
linux backup filesystems btrfs
asked Jan 20 at 6:26
eplepl
104
The problem here is that identifying what is a subvolume relies on metadata that you by definition don't want to copy (you only want a subvolume), so I don't think such a tool would be easy to write: It would have to modify this metadata, and keep track while doing so.
– dirkt
Jan 20 at 6:54
add a comment |
I recently built a system with a btrfs root partition. The most compelling reason for adopting btrfs compared to ext4, in my case, was live copy-on-write snapshots, with near-zero latency. Compared to ext4, when a full system backup entailed taking down the system, mounting from a live distribution, and building a partclone image on removable media, the promise of snapshots is that the snapshot can be captured on the backup media while the system is live.
To my astonishment, no tool exists, however, that will capture the entire snapshot to a single file on external media, such that if the system is restored from that file, all applications will have the same view of the filesystem as before the crash (except that the other snapshots or subvolumes are missing).
The documentation suggests mirroring the directory tree using a tool such as rsync, or using btrfs-send/btrfs-receive to capture the incremental changes on another system. In the first case, I have always found it nearly impossible to recreate all the metadata in a file tree exactly by mirroring a file tree rather than imaging the file system, and have little optimism that a restore would be very smooth. I always find that some metadata, be it permissions, timestamps, hidden files, or so on, are not properly captured. The problem is compounded when the transfer occurs across file systems of different types. The other suggestion assumes another btrfs file system is available, which is not always the case.
Are any suggestions available for saving or restoring a volume-level image, similar to a partclone file, but representing only a select subvolume?
linux backup filesystems btrfs
asked Jan 20 at 6:26
eplepl
104
I recently built a system with a btrfs root partition. The most compelling reason for adopting btrfs compared to ext4, in my case, was live copy-on-write snapshots, with near-zero latency. Compared to ext4, when a full system backup entailed taking down the system, mounting from a live distribution, and building a partclone image on removable media, the promise of snapshots is that the snapshot can be captured on the backup media while the system is live.
To my astonishment, no tool exists, however, that will capture the entire snapshot to a single file on external media, such that if the system is restored from that file, all applications will have the same view of the filesystem as before the crash (except that the other snapshots or subvolumes are missing).
The documentation suggests mirroring the directory tree using a tool such as rsync, or using btrfs-send/btrfs-receive to capture the incremental changes on another system. In the first case, I have always found it nearly impossible to recreate all the metadata in a file tree exactly by mirroring a file tree rather than imaging the file system, and have little optimism that a restore would be very smooth. I always find that some metadata, be it permissions, timestamps, hidden files, or so on, are not properly captured. The problem is compounded when the transfer occurs across file systems of different types. The other suggestion assumes another btrfs file system is available, which is not always the case.
Are any suggestions available for saving or restoring a volume-level image, similar to a partclone file, but representing only a select subvolume?
linux backup filesystems btrfs
linux backup filesystems btrfs
asked Jan 20 at 6:26
eplepl
104
asked Jan 20 at 6:26
eplepl
104
edited Jan 20 at 6:58
epl
asked Jan 20 at 6:26
eplepl
104
asked Jan 20 at 6:26
eplepl
104
asked Jan 20 at 6:26
eplepl
104
104
The problem here is that identifying what is a subvolume relies on metadata that you by definition don't want to copy (you only want a subvolume), so I don't think such a tool would be easy to write: It would have to modify this metadata, and keep track while doing so.
– dirkt
Jan 20 at 6:54
add a comment |
The problem here is that identifying what is a subvolume relies on metadata that you by definition don't want to copy (you only want a subvolume), so I don't think such a tool would be easy to write: It would have to modify this metadata, and keep track while doing so.
– dirkt
Jan 20 at 6:54
The problem here is that identifying what is a subvolume relies on metadata that you by definition don't want to copy (you only want a subvolume), so I don't think such a tool would be easy to write: It would have to modify this metadata, and keep track while doing so.
– dirkt
Jan 20 at 6:54
The problem here is that identifying what is a subvolume relies on metadata that you by definition don't want to copy (you only want a subvolume), so I don't think such a tool would be easy to write: It would have to modify this metadata, and keep track while doing so.
– dirkt
Jan 20 at 6:54
add a comment |
1 Answer
1
active
oldest
votes
btrfs send and btrfs receive are exactly the tools you need.
I have always found it nearly impossible to recreate all the metadata in a file tree exactly by mirroring a file tree rather than imaging the file system, and have little optimism that a restore would be very smooth. I always find that some metadata, be it permissions, timestamps, hidden files, or so on, are not properly captured.
Have you tried the tools? I have had no such problems with btrfs. btrfs send and btrfs receive do not work with files, they work with entire subvolumes, having access to all Btrfs metadata natively.
The problem is compounded when the transfer occurs across file systems of different types. The other suggestion assumes another Btrfs file system is available, which is not always the case.
You will need another Btrfs filesystem only if you want to replicate the subvolume there. This is often desirable, so you can mount it and get access to its files. And this is unavoidable, if you want to backup your subvolumes incrementally. You need the exact previous snapshot(s) in both places to incrementally send the next one.
With full dump, however, you get a standalone stream, which is exactly an image (but not a browsable backup, unless you btrfs restore it). Work with it like with any other stream:
btrfs send /source/subvolume >/another/filesystem/subvolume-image # just a file
# (or you can gzip it and/or send with nc on the fly, whatever)
# then later
</another/filesystem/subvolume-image btrfs receive /some/btrfs/directory
Where /some/btrfs/directory may belong to the same Btrfs filesystem as /source.
answered Jan 20 at 7:38
Kamil MaciorowskiKamil Maciorowski
26.8k155781
To be clear, my requirements are 1) capture an entire, single subvolume, 2) into a single file (or small group), 3) that can be stored as regular files on any external FS of any type. The purpose is crash recovery after equipment failure (akin to partclone for full partitions), not live, browsable, replicated instances. I have not tried thesendcommand because I understood that it is only useful for exchange between two livebtrfspartitions. Are you saying that I can use the command as in your example to capture a minimal but full dump of all data and metadata for a single subvolume?
– epl
Jan 20 at 7:57
@eplAre you saying that I can use the command as in your example to capture a minimal but full dump of all data and metadata for a single subvolume?– I believe so. Yes.
– Kamil Maciorowski
Jan 20 at 9:31
That is very nice. The tutorials indicate thatbtrfshas no solution for backups, and other tools such asrsyncare recommended. I wish that they instead would indicate thatbtrfshas a great backup system. To create a backup, one first simply makes a snapshot, and then dumps the snapshot to a file usingbtrfs send. To test this approach online, I suppose I could very easily dump a snapshot to a file and then it restore to an empty subvolume from that file?
– epl
Jan 21 at 1:34
@eplbtrfs sendlooks OK when it comes to a full copy of a single subvolume, but for many of them sharing data blocks, and for incremental backups, the situation gets complicated. See this answer. In such case storing backups as files leads to problems: (1) Restoring must be done in proper sequence. (2) Incremental backups require you to store new files, while you cannot really delete old ones. (3) Non-incremental backup transfers some data again. // Unless the file holds a Btrfs filesystem you mount andbtrfs restoreto on the fly.
– Kamil Maciorowski
Jan 21 at 5:55
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
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',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1396241%2fbtrfs-imaging-a-volume-to-an-external-file%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
btrfs send and btrfs receive are exactly the tools you need.
I have always found it nearly impossible to recreate all the metadata in a file tree exactly by mirroring a file tree rather than imaging the file system, and have little optimism that a restore would be very smooth. I always find that some metadata, be it permissions, timestamps, hidden files, or so on, are not properly captured.
Have you tried the tools? I have had no such problems with btrfs. btrfs send and btrfs receive do not work with files, they work with entire subvolumes, having access to all Btrfs metadata natively.
The problem is compounded when the transfer occurs across file systems of different types. The other suggestion assumes another Btrfs file system is available, which is not always the case.
You will need another Btrfs filesystem only if you want to replicate the subvolume there. This is often desirable, so you can mount it and get access to its files. And this is unavoidable, if you want to backup your subvolumes incrementally. You need the exact previous snapshot(s) in both places to incrementally send the next one.
With full dump, however, you get a standalone stream, which is exactly an image (but not a browsable backup, unless you btrfs restore it). Work with it like with any other stream:
btrfs send /source/subvolume >/another/filesystem/subvolume-image # just a file
# (or you can gzip it and/or send with nc on the fly, whatever)
# then later
</another/filesystem/subvolume-image btrfs receive /some/btrfs/directory
Where /some/btrfs/directory may belong to the same Btrfs filesystem as /source.
answered Jan 20 at 7:38
Kamil MaciorowskiKamil Maciorowski
26.8k155781
To be clear, my requirements are 1) capture an entire, single subvolume, 2) into a single file (or small group), 3) that can be stored as regular files on any external FS of any type. The purpose is crash recovery after equipment failure (akin to partclone for full partitions), not live, browsable, replicated instances. I have not tried thesendcommand because I understood that it is only useful for exchange between two livebtrfspartitions. Are you saying that I can use the command as in your example to capture a minimal but full dump of all data and metadata for a single subvolume?
– epl
Jan 20 at 7:57
@eplAre you saying that I can use the command as in your example to capture a minimal but full dump of all data and metadata for a single subvolume?– I believe so. Yes.
– Kamil Maciorowski
Jan 20 at 9:31
That is very nice. The tutorials indicate thatbtrfshas no solution for backups, and other tools such asrsyncare recommended. I wish that they instead would indicate thatbtrfshas a great backup system. To create a backup, one first simply makes a snapshot, and then dumps the snapshot to a file usingbtrfs send. To test this approach online, I suppose I could very easily dump a snapshot to a file and then it restore to an empty subvolume from that file?
– epl
Jan 21 at 1:34
@eplbtrfs sendlooks OK when it comes to a full copy of a single subvolume, but for many of them sharing data blocks, and for incremental backups, the situation gets complicated. See this answer. In such case storing backups as files leads to problems: (1) Restoring must be done in proper sequence. (2) Incremental backups require you to store new files, while you cannot really delete old ones. (3) Non-incremental backup transfers some data again. // Unless the file holds a Btrfs filesystem you mount andbtrfs restoreto on the fly.
– Kamil Maciorowski
Jan 21 at 5:55
add a comment |
btrfs send and btrfs receive are exactly the tools you need.
I have always found it nearly impossible to recreate all the metadata in a file tree exactly by mirroring a file tree rather than imaging the file system, and have little optimism that a restore would be very smooth. I always find that some metadata, be it permissions, timestamps, hidden files, or so on, are not properly captured.
Have you tried the tools? I have had no such problems with btrfs. btrfs send and btrfs receive do not work with files, they work with entire subvolumes, having access to all Btrfs metadata natively.
The problem is compounded when the transfer occurs across file systems of different types. The other suggestion assumes another Btrfs file system is available, which is not always the case.
You will need another Btrfs filesystem only if you want to replicate the subvolume there. This is often desirable, so you can mount it and get access to its files. And this is unavoidable, if you want to backup your subvolumes incrementally. You need the exact previous snapshot(s) in both places to incrementally send the next one.
With full dump, however, you get a standalone stream, which is exactly an image (but not a browsable backup, unless you btrfs restore it). Work with it like with any other stream:
btrfs send /source/subvolume >/another/filesystem/subvolume-image # just a file
# (or you can gzip it and/or send with nc on the fly, whatever)
# then later
</another/filesystem/subvolume-image btrfs receive /some/btrfs/directory
Where /some/btrfs/directory may belong to the same Btrfs filesystem as /source.
answered Jan 20 at 7:38
Kamil MaciorowskiKamil Maciorowski
26.8k155781
To be clear, my requirements are 1) capture an entire, single subvolume, 2) into a single file (or small group), 3) that can be stored as regular files on any external FS of any type. The purpose is crash recovery after equipment failure (akin to partclone for full partitions), not live, browsable, replicated instances. I have not tried thesendcommand because I understood that it is only useful for exchange between two livebtrfspartitions. Are you saying that I can use the command as in your example to capture a minimal but full dump of all data and metadata for a single subvolume?
– epl
Jan 20 at 7:57
@eplAre you saying that I can use the command as in your example to capture a minimal but full dump of all data and metadata for a single subvolume?– I believe so. Yes.
– Kamil Maciorowski
Jan 20 at 9:31
That is very nice. The tutorials indicate thatbtrfshas no solution for backups, and other tools such asrsyncare recommended. I wish that they instead would indicate thatbtrfshas a great backup system. To create a backup, one first simply makes a snapshot, and then dumps the snapshot to a file usingbtrfs send. To test this approach online, I suppose I could very easily dump a snapshot to a file and then it restore to an empty subvolume from that file?
– epl
Jan 21 at 1:34
@eplbtrfs sendlooks OK when it comes to a full copy of a single subvolume, but for many of them sharing data blocks, and for incremental backups, the situation gets complicated. See this answer. In such case storing backups as files leads to problems: (1) Restoring must be done in proper sequence. (2) Incremental backups require you to store new files, while you cannot really delete old ones. (3) Non-incremental backup transfers some data again. // Unless the file holds a Btrfs filesystem you mount andbtrfs restoreto on the fly.
– Kamil Maciorowski
Jan 21 at 5:55
add a comment |
btrfs send and btrfs receive are exactly the tools you need.
I have always found it nearly impossible to recreate all the metadata in a file tree exactly by mirroring a file tree rather than imaging the file system, and have little optimism that a restore would be very smooth. I always find that some metadata, be it permissions, timestamps, hidden files, or so on, are not properly captured.
Have you tried the tools? I have had no such problems with btrfs. btrfs send and btrfs receive do not work with files, they work with entire subvolumes, having access to all Btrfs metadata natively.
The problem is compounded when the transfer occurs across file systems of different types. The other suggestion assumes another Btrfs file system is available, which is not always the case.
You will need another Btrfs filesystem only if you want to replicate the subvolume there. This is often desirable, so you can mount it and get access to its files. And this is unavoidable, if you want to backup your subvolumes incrementally. You need the exact previous snapshot(s) in both places to incrementally send the next one.
With full dump, however, you get a standalone stream, which is exactly an image (but not a browsable backup, unless you btrfs restore it). Work with it like with any other stream:
btrfs send /source/subvolume >/another/filesystem/subvolume-image # just a file
# (or you can gzip it and/or send with nc on the fly, whatever)
# then later
</another/filesystem/subvolume-image btrfs receive /some/btrfs/directory
Where /some/btrfs/directory may belong to the same Btrfs filesystem as /source.
answered Jan 20 at 7:38
Kamil MaciorowskiKamil Maciorowski
26.8k155781
btrfs send and btrfs receive are exactly the tools you need.
I have always found it nearly impossible to recreate all the metadata in a file tree exactly by mirroring a file tree rather than imaging the file system, and have little optimism that a restore would be very smooth. I always find that some metadata, be it permissions, timestamps, hidden files, or so on, are not properly captured.
Have you tried the tools? I have had no such problems with btrfs. btrfs send and btrfs receive do not work with files, they work with entire subvolumes, having access to all Btrfs metadata natively.
The problem is compounded when the transfer occurs across file systems of different types. The other suggestion assumes another Btrfs file system is available, which is not always the case.
You will need another Btrfs filesystem only if you want to replicate the subvolume there. This is often desirable, so you can mount it and get access to its files. And this is unavoidable, if you want to backup your subvolumes incrementally. You need the exact previous snapshot(s) in both places to incrementally send the next one.
With full dump, however, you get a standalone stream, which is exactly an image (but not a browsable backup, unless you btrfs restore it). Work with it like with any other stream:
btrfs send /source/subvolume >/another/filesystem/subvolume-image # just a file
# (or you can gzip it and/or send with nc on the fly, whatever)
# then later
</another/filesystem/subvolume-image btrfs receive /some/btrfs/directory
Where /some/btrfs/directory may belong to the same Btrfs filesystem as /source.
answered Jan 20 at 7:38
Kamil MaciorowskiKamil Maciorowski
26.8k155781
answered Jan 20 at 7:38
Kamil MaciorowskiKamil Maciorowski
26.8k155781
answered Jan 20 at 7:38
Kamil MaciorowskiKamil Maciorowski
26.8k155781
answered Jan 20 at 7:38
Kamil MaciorowskiKamil Maciorowski
26.8k155781
26.8k155781
To be clear, my requirements are 1) capture an entire, single subvolume, 2) into a single file (or small group), 3) that can be stored as regular files on any external FS of any type. The purpose is crash recovery after equipment failure (akin to partclone for full partitions), not live, browsable, replicated instances. I have not tried thesendcommand because I understood that it is only useful for exchange between two livebtrfspartitions. Are you saying that I can use the command as in your example to capture a minimal but full dump of all data and metadata for a single subvolume?
– epl
Jan 20 at 7:57
@eplAre you saying that I can use the command as in your example to capture a minimal but full dump of all data and metadata for a single subvolume?– I believe so. Yes.
– Kamil Maciorowski
Jan 20 at 9:31
That is very nice. The tutorials indicate thatbtrfshas no solution for backups, and other tools such asrsyncare recommended. I wish that they instead would indicate thatbtrfshas a great backup system. To create a backup, one first simply makes a snapshot, and then dumps the snapshot to a file usingbtrfs send. To test this approach online, I suppose I could very easily dump a snapshot to a file and then it restore to an empty subvolume from that file?
– epl
Jan 21 at 1:34
@eplbtrfs sendlooks OK when it comes to a full copy of a single subvolume, but for many of them sharing data blocks, and for incremental backups, the situation gets complicated. See this answer. In such case storing backups as files leads to problems: (1) Restoring must be done in proper sequence. (2) Incremental backups require you to store new files, while you cannot really delete old ones. (3) Non-incremental backup transfers some data again. // Unless the file holds a Btrfs filesystem you mount andbtrfs restoreto on the fly.
– Kamil Maciorowski
Jan 21 at 5:55
add a comment |
To be clear, my requirements are 1) capture an entire, single subvolume, 2) into a single file (or small group), 3) that can be stored as regular files on any external FS of any type. The purpose is crash recovery after equipment failure (akin to partclone for full partitions), not live, browsable, replicated instances. I have not tried thesendcommand because I understood that it is only useful for exchange between two livebtrfspartitions. Are you saying that I can use the command as in your example to capture a minimal but full dump of all data and metadata for a single subvolume?
– epl
Jan 20 at 7:57
@eplAre you saying that I can use the command as in your example to capture a minimal but full dump of all data and metadata for a single subvolume?– I believe so. Yes.
– Kamil Maciorowski
Jan 20 at 9:31
That is very nice. The tutorials indicate thatbtrfshas no solution for backups, and other tools such asrsyncare recommended. I wish that they instead would indicate thatbtrfshas a great backup system. To create a backup, one first simply makes a snapshot, and then dumps the snapshot to a file usingbtrfs send. To test this approach online, I suppose I could very easily dump a snapshot to a file and then it restore to an empty subvolume from that file?
– epl
Jan 21 at 1:34
@eplbtrfs sendlooks OK when it comes to a full copy of a single subvolume, but for many of them sharing data blocks, and for incremental backups, the situation gets complicated. See this answer. In such case storing backups as files leads to problems: (1) Restoring must be done in proper sequence. (2) Incremental backups require you to store new files, while you cannot really delete old ones. (3) Non-incremental backup transfers some data again. // Unless the file holds a Btrfs filesystem you mount andbtrfs restoreto on the fly.
– Kamil Maciorowski
Jan 21 at 5:55
To be clear, my requirements are 1) capture an entire, single subvolume, 2) into a single file (or small group), 3) that can be stored as regular files on any external FS of any type. The purpose is crash recovery after equipment failure (akin to partclone for full partitions), not live, browsable, replicated instances. I have not tried the
send command because I understood that it is only useful for exchange between two live btrfs partitions. Are you saying that I can use the command as in your example to capture a minimal but full dump of all data and metadata for a single subvolume?– epl
Jan 20 at 7:57
To be clear, my requirements are 1) capture an entire, single subvolume, 2) into a single file (or small group), 3) that can be stored as regular files on any external FS of any type. The purpose is crash recovery after equipment failure (akin to partclone for full partitions), not live, browsable, replicated instances. I have not tried the
send command because I understood that it is only useful for exchange between two live btrfs partitions. Are you saying that I can use the command as in your example to capture a minimal but full dump of all data and metadata for a single subvolume?– epl
Jan 20 at 7:57
@epl
Are you saying that I can use the command as in your example to capture a minimal but full dump of all data and metadata for a single subvolume? – I believe so. Yes.– Kamil Maciorowski
Jan 20 at 9:31
@epl
Are you saying that I can use the command as in your example to capture a minimal but full dump of all data and metadata for a single subvolume? – I believe so. Yes.– Kamil Maciorowski
Jan 20 at 9:31
That is very nice. The tutorials indicate that
btrfs has no solution for backups, and other tools such as rsync are recommended. I wish that they instead would indicate that btrfs has a great backup system. To create a backup, one first simply makes a snapshot, and then dumps the snapshot to a file using btrfs send. To test this approach online, I suppose I could very easily dump a snapshot to a file and then it restore to an empty subvolume from that file?– epl
Jan 21 at 1:34
That is very nice. The tutorials indicate that
btrfs has no solution for backups, and other tools such as rsync are recommended. I wish that they instead would indicate that btrfs has a great backup system. To create a backup, one first simply makes a snapshot, and then dumps the snapshot to a file using btrfs send. To test this approach online, I suppose I could very easily dump a snapshot to a file and then it restore to an empty subvolume from that file?– epl
Jan 21 at 1:34
@epl
btrfs send looks OK when it comes to a full copy of a single subvolume, but for many of them sharing data blocks, and for incremental backups, the situation gets complicated. See this answer. In such case storing backups as files leads to problems: (1) Restoring must be done in proper sequence. (2) Incremental backups require you to store new files, while you cannot really delete old ones. (3) Non-incremental backup transfers some data again. // Unless the file holds a Btrfs filesystem you mount and btrfs restore to on the fly.– Kamil Maciorowski
Jan 21 at 5:55
@epl
btrfs send looks OK when it comes to a full copy of a single subvolume, but for many of them sharing data blocks, and for incremental backups, the situation gets complicated. See this answer. In such case storing backups as files leads to problems: (1) Restoring must be done in proper sequence. (2) Incremental backups require you to store new files, while you cannot really delete old ones. (3) Non-incremental backup transfers some data again. // Unless the file holds a Btrfs filesystem you mount and btrfs restore to on the fly.– Kamil Maciorowski
Jan 21 at 5:55
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1396241%2fbtrfs-imaging-a-volume-to-an-external-file%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
The problem here is that identifying what is a subvolume relies on metadata that you by definition don't want to copy (you only want a subvolume), so I don't think such a tool would be easy to write: It would have to modify this metadata, and keep track while doing so.
– dirkt
Jan 20 at 6:54