GEO <1g2e3o4@xxxxxxxxx> schrieb: > First of all, I am sorry that I screw up the whole structure of the > discussion (I have not subscribed to the mailing list, and as Kai replied > to the mailing list only, I could not reply to his answer.) Umm... Try a NNTP gateway like gmane to follow the list in an NNTP news reader of your choice. You can be semi-autosubscribed then without getting email sent to your email inbox and without digests being sent. It's really enjoyable. > Kai: Yeah, your point was neutral and I did never understand it otherwise. > Thank you for your answer! NP. > I already had idea of creating a subvolume called DATA in my home > directory, however I find that pretty annoying, as most applications will > open home by default. Well, I mentioned you may want to place symlinks into that data directory for the well-known home directory locations like "music", "documents", etc. It's a bit ugly but it should do the job well. You can make your data directory hidden by naming it ".my-backup-data" or something, then point symlinks into that for documents, music, etc. That way, the applications still open your home fine, it is not cluttered with your data directory and the symlinks will serve fine. It may not be what you prefer but it can be an elegant solution. But there you go: > In fact I would find it more elegant to generally backup without making > changes to my file system structure in home. > > I know that there other possibilities to do what I want, but I am asking > whether the initially described method would work reliably, given that the > user makes not a fundamental mistake himself. > I know it may sound stubborn but I am really interested if my method works > just as reliable as the other suggested methods. Given that there are no mistakes in your procedure to do the preparation jobs for your backup, it should work perfectly reliable. I think, btrfs send/receive still has some quirks handling corner cases - and those may well be triggered by your idea of cleaning up the snapshot first, but generally it should work (at least if btrfs send/receive work as intended, there are no design decisions which would work against your use-case). > As I am not having the level required to check the code myself, I am > asking here, in the hope someone knowing the code could state if it should > work or not. Putting potential bugs aside (btrfs is still experimental, btrfs send/receive still has many corner-case quirks), it will work. But the design of your process to prepare the backup will put a lot of unnessecary work to your btrfs (in comparision to the alternatives already outlined here), increasing fragmentation, meta-data allocation, and probably making btrfs send/receive less efficient. So to conclude: Your approach will probably be a good test scenario for btrfs send/receive and snapshots. But I really wouldn't try it without having a known-to-work backup up your sleeve. -- Replies to list only preferred. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
