[Backalaika-developers] Re: quirements and design

[Nando F. <nan...@ma...>]

Detailed requirementes and design ideas for backup and restore
==============================================================

// BackupServer shall store a list of
struct Computers
{
   string ComputerName; // max 8 characters!
   string Host;
   int Port;            // positive number
   string OldNames;     // Allows ComputerName to be changed and 

                        // old backups to be mapped to it
}

A backup profile  can only refer to 1 computer.
A backup profile  can contain multiple BaseFolders in that computer.
Multiple profiles can refer to a computer.
Visualization of this:
Computer
   Profile1
     BaseFolder1
     BaseFolder2
   Profile2
     BaseFolder3
     BaseFolder4

Backups will be stored by BackupServer, whose XML configuration should 
be like this:
struct BackupServerSettings
{
   string BackupsFolder;
   int    BackupServicePort;
   struct PortRange
   { // for connecting to ZipServers
     int MinPort;
     int MaxPort;
   }
}

Directory structure for storing backups:
BackupsFolder    // only 1
   Media001       // multiple folders, each representing one DVD-R or 
whatever
     ProfileName  // multiple
       (zip files go here)

Because ProfileName here becomes a directory name, it shall not contain 
spaces nor be longer than 10 chars, and cannot contain 
filename-unfriendly chars. This *validation* must be added to the 
ProfileSingle class.

There will be *one zip file for each BaseFolder* defined in a profile.
This is important because e.g. if a profile defines a backup for both my 
C: and D: drives, their contents won't get mixed in a single .zip file.

(The alternative was to have *one zip per profile*. We would need to 
store absolute pathnames (including drive letter) into the zip, which is 
weird and not what a user would expect when using a common zip utility.)

The *name of each zip file* will be DateTime-Kind.zip where DateTime is 
the backup moment in the form 2004-12-31T15.30.45 and Kind will be 4 
letters: Full or Diff or Incr.

*Advantages* of this filename scheme
- Unique filenames (as long as 2 backups aren't started in the same second)
- Short  filenames
*Disadvantage*
- Does not describe the contents of a zip file (which would be hard to 
do in so few characters anyway)

To allow easy, automated restoration of such backups, we need an XML 
file to accompany each zip file, providing more information about it.
Each XML file will have the same name as the zip file it refers to, 
except for the .xml extension.
The struct for this XML looks like this:

struct Job
{
   string ComputerName;  // defined above
   string ProfileName;   // idem
   string BaseFolder;    // idem
   BackupKinds Kind;     // Full, Differential or Incremental
   DateTime JobTime;     // same DateTime that goes into file name
}

These XML files will allow us to...

Restore by
   ComputerName AND JobTime
     ProfileName OR
     BaseFolder

This is to say:
- We can do a restore if user inputs only ComputerName and a date
- We can do a finer (smaller) restore if user additionally inputs either 
a BaseFolder or a ProfileName (in the latter case, all zip files 
referring to this ProfileName get restored, resulting in multiple 
BaseFolders being restored).

Am I missing anything?

Anyone with me?

Nando