[EMAIL PROTECTED] wrote: > Hello, > > Thanks for your reply. > > Selon Jon Radel <[EMAIL PROTECTED]>: > >> Rémi Boulle wrote: > >>> For what I understood dirvish write only the changed parts of the >>> changed files. >> While, if backing up across the network, rsync transfers only the >> changed portions of changed files, what is written to disk is the entire >> changed file. > > Ok, so dirvish "just" add the part sent by rsync with the unchanged part > already > on the hard drive ? >
Actually, rsync handles all that for dirvish. Dirvish, to be very vague and high level, basically says to rsync "make this directory on the local machine look just like that one over on the remote machine--and here's the directory that contains the last copy of you made of the remote directory so try to minimize the work and disk space you use." >>> My first image is roughly 5 Go, so why the second one is 5Go too ? (no >>> files were changed) >> How did you measure this? > > Right click/properties ;-) (on ubuntu) Don't take this too personally, but sometime you're going to either learn to take everything your GUI is doing on faith or learn what it's really doing behind the scenes. :-) I suspect it's actually calling du. > >> If you simply ran du against each image, then >> yes, they would both show as 5 gig. However, if you run du against both >> images at the same time, it should still show about 5 gig and not 10 >> gig. > > So individually they use 5 gig each and globally they use 5gig + epsilon ? > If the files are all exactly alike (and we ignore any soft links you might have) then epsilon consists essentially of a second set of directory entries. >> Each image is equal, in the sense that no image is the "full >> backup" and other images are the "differential backup." They're all >> "full," some were just made earlier, but there is only one copy of each >> unchanged, unmoved file physically taking up blocks on the hard drive. > > Ok, so eg the second image as a 5 gig space *reserved* on the filesystem (but > not used). Nope. The second image is a new set of directory entries pointing to the same data blocks on disk that the first set of directory entries point at. None of this is likely to make much sense until you understand how hard links work in Unix file systems, and you're better off with an explanation in some competent book (or check wikipedia--there's probably something decent there) than me trying to write something quick and semi-coherent. > >> This all assuming that you've not made any configuration errors, or run >> dirvish with the --init option more than once, or changed critical >> configuration choices between backups. It *is* possible to create >> backups that have no link with each other. (Which many of us do >> deliberately for extra safety. > >>From a disk space point of view it is totally equal no ? The only difference >>is > from network load point of view... > > Am I right ? :-) > > Hum, so, is it possible to make differential backups everyday day and, once a > month, a total backup (I mean with no link) ? > Hmmmm.... I *think* you're confused, but I'm not certain. Learn about hard links and it should all make more sense. >>> Does it mean that all those images are "real" images ? eg I can delete >>> last monday image without having any problems ? >>> >> Unless you want to restore a file that was captured only in that backup. >> :-) If you delete the last successful backup, you'll have to run >> dirvish with the --init option again. Other than that, you can delete >> any image without an issue. > > So the "mustn't to be touched" backups are the first one and the last one ? Not exactly. Some of this depends on policy, but some general guidelines: Last one: Probably don't want to delete this, as it is, of course, your more recent backup. Recent ones: Probably don't want to delete any that are recent enough that there's a chance that you've not yet discovered the silly mistake you made while editing your favorite file. In other words, if you destroy the contents of your file on Monday and don't discover this until Friday, you'll really glad that you have Sunday's backup too and not only Thursday's. Last remaining successful backup: As stated above, it is more convenient to have at least one fully successful backup in place, otherwise your automated scripts will probably fail and you'll have to manually run dirvish with --init. However, this does *not* have to be the first backup. It can be any backup. So far as dirvish is concerned, all the backups are of equivalent status and validity. (This is the reason that dirvish's own expire script will refuse to delete the last successful backup.) You'll see plenty of example configuration files where you'll note that all backups are deleted by the time they're a year or two old. --Jon Radel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Dirvish mailing list Dirvish@dirvish.org http://www.dirvish.org/mailman/listinfo/dirvish
