Re: [Burp-users] Plan to test protocol 2

[Graham K. <gr...@gr...>]

On Fri, Jun 15, 2018 at 11:34:46AM +0000, Iznohak via Burp-users wrote:
> I'm planning to test protocol 2 as follows:
> 
> - Set up the client to backup a subset of data with protocol 2.
> - The same data is also backed up with protocol 1 (in case something goes wrong with proto 2, and for comparison purpose).
> - The client will have 2 configurations, one for proto 1 and one for proto 2. They will be identical configurations, except the cname so they can be differentiated by the server (e.g. cname-p1 and cname-p2).
> - The client will be backed up, daily or more often, to server with proto 1 and proto 2 in sequence.
> - Restores of random backups will be performed periodically, and compared between proto 1 and 2.
> - Server-side storage will be monitored closely. Server- and client-side performance may be monitored if possible.
> - There will be 2 clients: 1 Windows and 1 macOS.
> - The server is a NAS running Linux.
> - Not testing Linux clients.
> 
> My primary areas of concern are reliability and accuracy of backups/restores, storage utilization and robustness over time, and to a lesser degree CPU/memory utilization on the client. I'm not concerned about performance (e.g. latency, throughput) or scalability (e.g. large datasets or high number of clients). The data subset and the changes to be backed up for this test will be fairly small anyway.
> 
> Does that sound ok? Any gotcha I'm missing with such a setup?

Hello,

This sounds very nice, thank you for testing.

My main concerns about protocol2 in general are:

a) Robustness over time - I think that the sparse index file will grow forever
and one day become too big. It is probably recoverable by manually deleting
some of it, but I would like it to be automatic.

b) Restore speed, although some changes went in recently that help this, and
you probably won't notice if your backups are small.

c) Corruption of a block in a shared data file rendering many files
unrestorable - this is not a worry in protocol1 as each filename is a separate
entity on disk.