On 12/23/2010 5:45 PM, Dermot Beirne wrote:
> Hi Dan,
>
>
>>
>> According to the above, Media ID 896 has a retention period of 2,851,200
>> seconds (or 33 days).
>>
>
> That's correct, and that's what I would expect.
>
>>
>> Aren't Job and File retention specific to a client, not a Volume?
>>
>
> I know they can be specified on the client side, but I though pool
> definitions (where I have defined them) over rides this. I only
> specify a job retention there because it's mandatory, but ignored if
> defined in the pool. Am I wrong?
>
>> What I do, or have tired, and have not tested is putting Job and File
>> retention to a value equal to the maximum Pool retention value.
>>
>> Thus, in your case, your maximum Volume retention is 10 years. I suggest
>> you want Job and File retention set at 10 years.
>>
>> Would that help you?
>>
>
> I'm not sure why it would help, as it appears to be ignoring my
> current retention times at the moment.
> Do you know if the retention periods of the new pool (post migration)
> are applied to the jobs that are migrated. It looks like the disk
> pool retentions (just a few days) are being used instead.
>
> If I specify a 10 year retention on the clients definition for jobs
> and files, will this not mean an endlessly growing database that never
> gets pruned.
Yes, for 10 years. But retain perspective. There will be one entry in
the database for every file name and every path name. And one entry for
every file in every backup. How many files are in each backup, more or
less?
I don't prune until after three years. If I need to restore, the last
thing I want to do is deal with bscan. Overall, I believe the obsession
with pruning is easily overridden by the hassles of restoring when
File/Job records do not exist.
To give you an idea of my situation (commas added by me):
[dan@ngaio:~] $ psql bacula
psql (8.4.5)
Type "help" for help.
bacula=# select count(*) from file;
count
---------
8,274,704
(1 row)
bacula=# select count(*) from filename;
count
---------
2,307,279
(1 row)
bacula=# select count(*) from job;
count
-------
9,056
(1 row)
bacula=# select count(*) from jobmedia;
count
-------
13,765
(1 row)
bacula=# select count(*) from path;
count
--------
181,568
(1 row)
bacula=#
How big is my database on disk?
bacula=# select pg_size_pretty(pg_database_size('bacula'));
pg_size_pretty
----------------
3031 MB
(1 row)
3GB. That includes indexes etc. When dumped to disk, that becomes 1GB,
or about 375MB, compressed.
The oldest full backup in that database is dated 2005-01-31 21:14:25, so
that is 6 years of backups. A straight guess, for my situation, 10
years of backups would occupy 10GB of disk space.
I think disk space is cheap compared to the time and bscan frustration.
Just something to consider.
--
Dan Langille - http://langille.org/
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
