Druvaa inSync Roadmap

We receive numerous requests for throwing some light on inSync’s roadmap, so here it is. We have tried to include most of the  suggestions we received from the users. At the same time, we did not go for some features as they do not fit in our vision for data protection. We discuss our view point about some of such  features towards the end of this blog entry.

Our focus, as always, is ”Light-weight, Simple, Fast and Trustable” backup solution.

Version 2.2 (Oct 10th, 2008)

1. Admin configured backup folders - The admin can choose “must have” folders for backup for each profile. Can also choose if user can configure more folders.
2. Browser Restore - Enable user to restore files and folders using just the browser, when he is not at his desk.
3. Linux Port (beta) - Initially support Ubuntu 8+, openSuse 10+ and RHEL 5+
4. Advanced Reporting - 6 different reporting option for flexible and detailed reporting.
5. Dump user data locally (on server) while disabling the user.
6. Restore user data on server - We plan to allow a dumping user data locally (on server) in case a user is in disabled state. This could be useful for archiving a user’s data before the deleting the user.
7. Publish configuration API - Publish the server configuration API to enable third party software vendors to integrate inSync backup in their management console.

Version 3.0 (Dec 21th, 2009)

1. Full PC Backup - Use de-duplication to effectively backup entire PC (operating system, application executables in addition to the application configuration and data)
2. Bare-metal Restore - Use restore points created by full PC backup to restore a machine that does not have a working operating system.
3. Performance Improvements - for large (1GB+) file incremental backup.
4. Search in Restore - Search files in restore.

Excluded Features

The features which we believe should not be implemented even though some key players offer them -

1. Disable inSync client’s desktop visibility - Don’t show the inSync client running on the the user’s PC to hide backup. In our opinion, this is not a solution. The right approach is to provide a light weight backup solution that does not hamper the PC performance and hence, the user does not want to disable it.
2. Server initiated backup- It is not useful for the PC backup environment, especially for mobile laptops that are not always connected. we may consider this for the server version of inSync.
3. Allow USB backup or tape backup on users PC - We believe that media based backup is inherently unusable. With falling disk prices and Druvaa’s data de-duplication technology, the best backup policy is to maintain backups on hard-disks.

9 comments September 24th, 2008

Encode configuration files in python

Python is a powerful languauge for encoding configuration information for a software program. Especially the dictionary contruct and the ability to nest data structures allows to encode complex configuration parameters. Also storing the configuration as a text file allows for easier debugging and manual editing of the configuration. For example, the unix passwd file can be encoded as a dictionary with the user name as the key. Each entry in the dictionary would be another dictionary with name, uid, etc. as keys or it could be a tuple with fixed positions for name, uid, etc.

Offcourse since python is not designed to be used for encoding configuration, it does not directly provide routines to load  and save configuration files written as python scripts. Saving the configuration file is fairly simple as the str method cleanly converts any python data structure to a string that can be directly written to a file. Note that for a string type configuration parameter, you need to explicitely add quotes while writing to the file. The python code to save a configuration file myconfig.cfg would look like
follows:

f = open(”/path/to/myconfig.cfg”, “w”)
f.write(”some_config_param = “)
f.write(str(some_config_param))
f.write(”\n”)

Loading a configuration file written as python data structures and then accessing the configuration information seemlessly is slightly more complex. Using the imp module is one possible way to load the configuration file. The imp module provides two functions, find_module to search for a module using the standard heuristics and load_module to load the file found by find_module and return a module object. The return values of find_module are to be passed to load_module as parameters. Once the module object is available, one can access the configurtion information through its attributes. There are couple of issues with using the imp module.

• The file needs to have a .py extension since findmodule searches files with only certain extentions and guesses the type of the file from the extension. This can be worked around by opening the config file instead of using find_module and passing the open file to load_module.
• The load_module method compiles the file as a .pyc file before importing it. That leaves a unrequired file behind. The compiled file is used by load_module if it is newer than the config file. In case of a race between two threads, one saving the config file and the other one loading it, the compiled file could get a timestamp same as the config file but with the old contents. Any further load_module calls load from the compiled file and hence, load the old config data.

The execfile function is a better way to load a configuration file. Again, the execfile method is not intended for loading python data structures. It’s primary use is to run an independent piece of python code. But the function allows us to specify the global and local dictionaries as parameters. Also, the effects of the executed code are reflected in the parameters. The python code to load a configuration file myconfig.cfg would look like follows:

configuration_globals = {}
configuration_locals = {}
execfile(”/path/to/myconfig.cfg”, configuration_globals, configuration_locals)
some_config_param = configuration_locals["some_config_param"]

Happy programming!

Add comment March 6th, 2008