Hello,
Migration:
This is to let you know that the Bacula migration project is advancing nicely,
though it is about 6 weeks behind schedule mostly due to an unplanned 1 month
vacation and 2 weeks of little work because of a virus.
I've now got all the basic parts working quite well and they pass two new
migration regression scripts, the first of which does two backups, then
requests a migration of all jobs named *save, and finally does a restore. The
second does several backups, then requests a migration of all volumes named
Full* (or something similar), and then does a restore from one of the
migrated jobs.
There are many other forms of migration, but they should be completed rather
quickly as most are just a question of getting the SQL correct.
More problematic will be to try to detect and avoid as many Volume/drive
deadlock situations as possible. Currently Bacula has no Volume/drive
deadlock detection, because it has not been really critical, but with
migration, if you try to migrate from a Volume onto the same Volume, a
deadlock will arise since it is not possible to read from and write to the
same volume simultaneously (at least if it is a tape).
Over the next week, I am going to try to verify that the database schema as
exists today is complete and that the upgrade scripts (untested) work. Once
that is done, and I document migration a bit, we can begin making beta
releases.
Restores:
Recently in thinking about restores and looking at the current Bacula tree
routines, I am convinced that it is relatively easy to make the current
Bacula restores optionally function in an incremental manner -- that is to
load one directory at a time as the user accesses that directory. This means
that a user with 6 million files in a Job could rather quickly do a Bacula
in-memory tree restore in selecting only one or two directories or
alternatively a few files. It would not be necessary to load the whole 6
million file entries in memory before the selection process can begin.
Unfortunately, if we are going to release version 1.40.0 before the end of the
year, this new idea must be put on the shelf until later.
Best regards,
Kern
Trivial stuff, but a bit incredible:
As most of you know, I have been slowed down because of what I call a dark
cloud hanging overhead consuming my time with problems (hardware, software).
Well, the cloud still seems to be here, but it is not striking me personally
anymore. Since getting my Autochanger repaired, disabling a bad DVD drive,
and switching distros, I have had essentially zero problems other than the
normal learning curve for the new distro.
On the other hand, the cloud has struck a charitable organization about 300
meters from where I live, where I happen to do volunteer system
administration (as well as Bacula backups, of course). First their firewall
apparatus went belly up, and when I replaced it with a brand new one, I found
the server dead. Well, the server, though limping along, is now suffering
from bus errors, and dying once a day. Though the cloud is not longer
striking me, I am still spending a lot of time resolving the damages caused
by this cloud ... It is about time it moved on, and hopefully it will take
the hot weather with it ... :-)
PS: more trivia while I have you on the line:
If anyone on the list understands X privileges, perhaps you could point me to
what needs to change to make X work between machines. Previously, I could
always run a graphical program on any of my computers on my network from my
development desktop after sshing to the remote machine. Now I find running as
non-root:
(on SuSE machine)
ssh Fedora-machine
yumex (a Python program that uses GTK)
yumex
You are attempting to run "yumex" which requires administrative
privileges, but more information is needed in order to do so.
Password for root:
Traceback (most recent call last):
File "/usr/share/yumex/yumexmain.py", line 24, in ?
import gtk
File
"/usr/src/build/612051-i386/install/usr/lib/python2.4/site-packages/gtk-2.0/gtk/__init__.py",
line 37, in ?
RuntimeError: could not open display
Normally the "Password for root:" should be in a GTK window.
Or even an ssh from SuSE to SuSE, and execute a Graphical program, I get:
kile: cannot connect to X server
Groan. I wonder if Novell knows what networking is. :-)
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users