Bacula-users

Re: [Bacula-users] [Bacula-devel] Idea/suggestion for dedicated disk-based sd

2010-05-04 13:35:24
Subject: Re: [Bacula-users] [Bacula-devel] Idea/suggestion for dedicated disk-based sd
From: Morty Abzug <morty AT frakir DOT org>
To: Craig Ringer <craig AT postnewspapers.com DOT au>
Date: Tue, 4 May 2010 13:33:12 -0400
On Tue, May 04, 2010 at 04:45:16PM +0800, Craig Ringer wrote:
> On 4/05/2010 11:45 AM, Morty Abzug wrote:
>
>> file dedup (rather than block dedup) could mostly be handled at the
>> catalog level with another level of indirection.  I.e. instead of a
>> catalog entry containing file metadata and where the file lives on
>> media, it would contain file metadata and a foreign key to a table
>> that maps hashes to where the file lives on the media.

> This is really hard to do when everything is bundled into big
> volumes, and volumes are expired as units. It'd be necessary to
> compltely re-design the way storage works to do file-level
> deduplication, and it's not as easy to do (efficiently, with proper
> retention etc) as it first seems either.

I think you could handle at least some of the retention issues by
comparing the current job's retention to the retention of the
job/volume for the old file.  If the backup of the old file doesn't
meet the new file's retention requirements, you back it up again.

However, format/architectural issues are indeed harder to overcome.
There are a number of limitations I have encountered with bacula, and
it looks like at least some of them might be fundamental to bacula's
architecture.  My list:

(1) no way to do a simple client check (AKA amcheck -c.)

(2) no way to do a simple tape check (AKA amcheck -lt)

(3) no automatic file-level deduplication.  "base jobs" are only a vague
    approximation

(4) no way to logically group hosts into a "run", with common options, the
    way amanda can.  Somewhat solvable with scripting.

(5) way too complex

(6) no proper client/server model.  bacula "clients" need inbound ports

(7) no support for native backups.

(8) no built-in support for fully-automated storage of recovery data.
    bacula recovery disks require a lot of manual work.

(9) no support for TOFU authentication.  Clients must be hand-configured.

(10) no support for Windows EFS

(11) no valid return codes from bconsole

(12) bconsole should support an option for execute-one-command (i.e. -e)

(13) bconsole should support an option for batch mode (i.e. -b)

(14) no support for "disable job=$job until $time"

(15) bconsole doesn't support control-c.

- Morty

------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users