The hidden email

[Madison Kelly]

Joseph Kubik wrote:
> First off, great work!

   Thank you! :)

> Questions:

   w00t! I love questions.

> -Do the device comments need to be unique?

   Nope. Comments are strictly for the user's benefit.

> -Do the Job comments need to be unique? (what is the job unique id?)

   Nope. THe Unique ID is assigned by the system when the device is 
first seen and can't be changed. This is what the program uses to ID the 
device inside the program which is why the comment can be so flexible.

> -I have some "large" datasets here at work, if you want me to test 
> anything in particular let me know.
> -what options are there for making the UI more drag and drop? Could a 
> gnome / kde app be built that could be in addition to the web interface?

   At this point having as many different scenarios tested with both 
small and large datasets is the biggest help people can give me (though 
I'm open for other kinds of help, too :) ). So if you get a change to 
try a very large dataset as a stress test I would very much be 
interested in the results.

> Suggestions:
> -If possible add a hook into the hotplug subsystem so that if a device 
> is added while you are looking at the devices / files menu you don't 
> have to hit refresh?

   The problem there would be how could I tell the client to reload the 
page without something like a Java applet? Being a standard web 
interface the connection between the client and server is torn down once 
the data has been passed.

> -SMB as destinations might be nice if you could come up with a clever 
> way to do it?

   Letting SMB (and vfat, etc) be destination partitions would be 
relatively trivial. Perhaps I should add a setting that a user could 
enable that would allow those partitions be destinations. The reason I 
don't currently allow them to be destinations is that Unix-style 
permissions can't be saved. If a user understands this and isn't 
concerned then it should be fine.

> -Add an option such that if a job is missed it runs at the next boot. 
> For running on desktop machines. Or, in case there was a clock jump and 
> cron missed.

   As Ian mentioned in the reply, there might be an alternative to 
'cron' that would support this. I was thinking of adding a method to 
switch out certain apps (like changing 'rsync' for 'rdiff' for the 
people who wanted versioning of source media). If something like 
'anacron' would solve this I could make 'cron' swappable as well.

> -Handle extended attributes as well. --see man (1) attr --

   May I ask, is this something that normally needs to be installed? I 
don't seem to have that on my system and 'attribute' is rather general. 
It seems that I missed something important along the way. :p

> -Add some way to do a onetime full system backup (including the boot 
> area). I'm not sure if there are already utilities that you could just 
> source for this?

   Hmm, I think 'dd' or something similar would do that. The biggest 
question would be writting the boot sector on the destination drive. 
Other than that though you could essentially do this already.

   On a given destination drive format it to be similar to your system's 
partition (like including a swap partition). Then create a backup job 
for each partition (ie: a job called 'boot partition', 'home partition', 
etc) and in each job tell it to backup only the specific source and set 
the destination partition it could use to be the equivelant partition on 
your destination device(s). Set the backup jobs to run back to back and 
you should have backup drives that are ready to boot.

   Perhaps to get around the boot record issue is to just set the proper 
partition on the destination drive to be bootable. After that you should 
be good to go with a 'bare-metal' recovery.

   You have peaked my interest! I will try this today myself and if it 
works I will add a section in the manual to describe exactly how to do this.

> -Add an option to create "virtual destinations" (loopback devices ) that 
> become cd isos and DVD isos that could then be burned.

   That is a good idea but it would also be bigger deal to tie into the 
program itself. If you manually create a loopback device the program 
should see it then you could treat it like any other destination.

   Again, I will try this (after the bare-metal test) and see if it 
works and document it if so.

> -Some way to do incremental backups (like rdif?)

   As I mentioned, I am thinking of a way to make certain apps like 
'rsync' replaceable. If I can do this then adding versioning should be 
as trivial as changing a setting.

> -Add some modularity so that people could add a database backup module. 
> Or any other custom app they wanted.

   The reason the v0.3 devel cycle will be "from scratch" is 
specifically to make the code modular. Not doing so in the first place 
was an oversight on my behalf. v0.4 will be the first full release that 
will be modular (and hopefully be the code base that will evolve from 
then on).

> -make the programs like rsync and df etc, easy to custom configure.

   The 'settings' menu was my attempt to do that. I have already decided 
though that v0.3/4 will just use a plain-text config file to simplify it 
further (the idea nehind in the program was to make it easier to access 
and edit but it added too much complexity and 'gotchas').

> -Add a way to do a gzip and archive (or tar / gzip) so that people  can 
> use the same UI even if they have limited space.

   Well, the idea behind not doing this originally was to simplify 
restore but enough people have asked for it that it will most likely be 
a feature in the next version.

> There's what I've got so far.
> -Joseph-

   That was wonderful, thank you very much!

Madison

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                       Madison Kelly (Digimer)
                TLE-BU, The Linux Experience; Back Up
Main project page:  http://tle-bu.org
Mailing lists:      https://sourceforge.net/mail/?group_id=120632
Community Forum:    http://tle-bu.org/cgi-bin/board/ikonboard.cgi
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml