On Thu, Apr 09, 2015 at 06:14:33PM +0200, Christoph Anton Mitterer wrote: > Hey. > > I wondered whether this is possible in btrfs (or could be > implemented),... it's in a way similar to send/receive, but AFAIU not > fully solvable with that. > > What I want to do is making incremental backups of a (btrfs) filesystem > to smaller mediums (that is for example: from a big RAID filesystem to > many BluRays or similar things). > > > Right now I make this as follows: > Every time backups should be made, I create a ext4 image which would > just fit inside the UDF fs of a BluRay (the ext4 image in turn is > dm-crypt encrypted) and copy as many *complete*[0] files from the source > filesystem to that image as possible. That image file is then burned to > BluRay. I also write an SHA512 sum of the whole image file to the BluRay > so that one can check whether it can be still read correctly. > Then the process continues with the remaining files. > > > The main idea behind writing only complete files to the separate parts > of the backup is, that I don't want to have a backup set, where I may > get into troubles if just one of the disks fails. > > > Obviously, when I would do regularly backups that way, then I'd write > each time a big amount of data which hasn't changed at all, which is not > just a costly issue, but also quite time consuming. > So ideally, I'd want to do just an incremental backup of all the files > that have been added/modified + the information of what has been > deleted/moved/changed it's properties. > > All that already smells quite a lot after making a snapshot at the last > backup, and then doing send/receive for the next one. > > > Now the problem, though, is, that I don't want to loose the property of > working in terms of complete files (and I guess send/recieve does not), > i.e. when a big file has just one block changed, I still would like to > have the complete file on the next incremental dump (and not just > information about the "diff"). > The only exception is when file metadata changes (i.e. pathname, date, > permissions, xattrs, etc.). If *just* one of these changes I wouldn't > want to backup the full raw data of the file again. > Any ideas whether and how this could be done / assisted by btrfs? btrfs sub find-new might be more helpful to you here. That will give you the list of changed files; then just feed that list to your existing bin-packing algorithm for working out what goes on which disks, and you're done. Hugo. -- Hugo Mills | Dullest spy film ever: The Eastbourne Ultimatum hugo@... carfax.org.uk | http://carfax.org.uk/ | PGP: E2AB1DE4 | The Thick of It
Attachment:
signature.asc
Description: Digital signature
