[Box Backup] Upgrading the client

[Ben Summers]

On 24 Sep 2004, at 08:54, richard_eigenmann wrote:

> I've thought up a scenario where the use of inodes to identify the file
> changes on the client is very problematic: moving your data and it's 
> backup
> to a new computer or upgrading your disk.
>
> Examples: you bought a new laptop and move your data and boxbackup to 
> the new
> machine. Or you run out of space and buy a new disk and move your data
> directories to that new drive.
>
> In this sort of situation boxbackup will detect a file change and will 
> back
> up everything to the store. Clearly this is undesirable.
>
> It gets highly problematic in the situation where you have huge 
> amounts of
> data say 30GB and your backup location is remote say via ADSL. If you 
> had 200
> kBit/s uplink that would translate to 416 hours of solid transfer or 
> 17 days.
>
> With the current software I would recommend taking the computer to the 
> backup
> server and connecting it directly to that Lan and making the big backup
> there.

Inode numbers are only used to work out file and directory renames. 
Timestamps are used for actual change detection. In fact, inode numbers 
simply wouldn't work for change detection, because they don't change 
when you modify the file.

In your scenario, in the worst case new attributes will be uploaded for 
every file. This doesn't take very long. However, if you're 
transferring a filesystem, you'll probably use something which 
maintains inode numbers and file attributes properly, so it won't be a 
problem at all. And anyway, you wouldn't be renaming or moving files 
around, all it takes is one scan to get the inode database up to date 
on the new machine.

(Yes, I have thought carefully about how Box Backup will be used and 
abused. I believe the design is robust and tolerant. It's certainly let 
me get away with things when bad stuff has happened.)

Ben