- Notes:
-
-Item 33: Commercial database support
- Origin: Russell Howe <russell_howe dot wreckage dot org>
- Date: 26 July 2006
- Status:
-
- What: It would be nice for the database backend to support more
- databases. I'm thinking of SQL Server at the moment, but I guess Oracle,
- DB2, MaxDB, etc are all candidates. SQL Server would presumably be
- implemented using FreeTDS or maybe an ODBC library?
-
- Why: We only really have one database server, which is MS SQL Server
- 2000. Maintaining a second one for the backup software (we grew out of
- SQLite, which I liked, but which didn't work so well with our database
- size). We don't really have a machine with the resources to run
- postgres, and would rather only maintain a single DBMS. We're stuck with
- SQL Server because pretty much all the company's custom applications
- (written by consultants) are locked into SQL Server 2000. I can imagine
- this scenario is fairly common, and it would be nice to use the existing
- properly specced database server for storing Bacula's catalog, rather
- than having to run a second DBMS.
-
-
-Item 34: Archive data
- Date: 15/5/2006
- Origin: calvin streeting calvin at absentdream dot com
- Status:
-
- What: The abilty to archive to media (dvd/cd) in a uncompressed format
- for dead filing (archiving not backing up)
-
- Why: At my works when jobs are finished and moved off of the main file
- servers (raid based systems) onto a simple linux file server (ide based
- system) so users can find old information without contacting the IT
- dept.
-
- So this data dosn't realy change it only gets added to,
- But it also needs backing up. At the moment it takes
- about 8 hours to back up our servers (working data) so
- rather than add more time to existing backups i am trying
- to implement a system where we backup the acrhive data to
- cd/dvd these disks would only need to be appended to
- (burn only new/changed files to new disks for off site
- storage). basialy understand the differnce between
- achive data and live data.
-
- Notes: Scan the data and email me when it needs burning divide
- into predifind chunks keep a recored of what is on what
- disk make me a label (simple php->mysql=>pdf stuff) i
- could do this bit ability to save data uncompresed so
- it can be read in any other system (future proof data)
- save the catalog with the disk as some kind of menu
- system
-
-Item 35: Filesystem watch triggered backup.
- Date: 31 August 2006
- Origin: Jesper Krogh <jesper@krogh.cc>
- Status: Unimplemented, depends probably on "client initiated backups"
-
- What: With inotify and similar filesystem triggeret notification
- systems is it possible to have the file-daemon to monitor
- filesystem changes and initiate backup.
-
- Why: There are 2 situations where this is nice to have.
- 1) It is possible to get a much finer-grained backup than
- the fixed schedules used now.. A file created and deleted
- a few hours later, can automatically be caught.
-
- 2) The introduced load on the system will probably be
- distributed more even on the system.
-
- Notes: This can be combined with configration that specifies
- something like: "at most every 15 minutes or when changes
- consumed XX MB".
-
-Kern Notes: I would rather see this implemented by an external program
- that monitors the Filesystem changes, then uses the console
- to start the appropriate job.
-
-Item 36: Implement multiple numeric backup levels as supported by dump
-Date: 3 April 2006
-Origin: Daniel Rich <drich@employees.org>
-Status:
-What: Dump allows specification of backup levels numerically instead of just
- "full", "incr", and "diff". In this system, at any given level, all
- files are backed up that were were modified since the last backup of a
- higher level (with 0 being the highest and 9 being the lowest). A
- level 0 is therefore equivalent to a full, level 9 an incremental, and
- the levels 1 through 8 are varying levels of differentials. For
- bacula's sake, these could be represented as "full", "incr", and
- "diff1", "diff2", etc.
-
-Why: Support of multiple backup levels would provide for more advanced backup
- rotation schemes such as "Towers of Hanoi". This would allow better
- flexibility in performing backups, and can lead to shorter recover
- times.
-
-Notes: Legato Networker supports a similar system with full, incr, and 1-9 as
- levels.
-Item 1: Implement a server-side compression feature
- Date: 18 December 2006
- Origin: Vadim A. Umanski , e-mail umanski@ext.ru
- Status:
- What: The ability to compress backup data on server receiving data
- instead of doing that on client sending data.
- Why: The need is practical. I've got some machines that can send
- data to the network 4 or 5 times faster than compressing
- them (I've measured that). They're using fast enough SCSI/FC
- disk subsystems but rather slow CPUs (ex. UltraSPARC II).
- And the backup server has got a quite fast CPUs (ex. Dual P4
- Xeons) and quite a low load. When you have 20, 50 or 100 GB
- of raw data - running a job 4 to 5 times faster - that
- really matters. On the other hand, the data can be
- compressed 50% or better - so losing twice more space for
- disk backup is not good at all. And the network is all mine
- (I have a dedicated management/provisioning network) and I
- can get as high bandwidth as I need - 100Mbps, 1000Mbps...
- That's why the server-side compression feature is needed!
- Notes: