W dniu 6 czerwca 2011 13:57 użytkownik Buschini Edouard
<moon AT ijaal DOT net> napisał:
Hello Radoslaw
Thank you for your answer.
I have to more questions because I discover a new command in Bconsole : "Prune"
To clean I use set the retention file at 0 days then I log in to Bconsole and "prune client=my_client" after that I select "Files" and finaly 'yes'. Do this action trucate all data associate to my_client ? I've got 115 critical server to backup, I don't want to mess this up :)
Pruning files means that you delete catalog database records about backuped files. It doesn't mean that you reclaim space allocated by a volume. If you want to reclaim a space allocated by volume then you have to purge a volume with proper action on purge setup.
2011/6/6 Radosław Korzeniewski
<radoslaw AT korzeniewski DOT net>
Hello,
2011/6/6 Buschini Edouard
<moon AT ijaal DOT net>
But today we have a big problem, we didn't anticipate a growing like that, on our FS we are at 97% of space used. It's very problematic. And since 1 week I'm working on free more space but it's very complicated with Bacula.
If you are doing a backup to disk (filesystem) then you can simply delete oldest/not required volume in bacula and rm it from filesystem.
I would, but datas from every Client are in the volume, so I cannot simply delete the volume, therefor we have a rotate of 4Go volumes.
You can migrate some clients/jobs with Migration Job Bacula feature or do it manually by bcopy utility. But you have to have additional space.
I've search every where but I didn't find any exploitable answers so I'm asking here.
Do you have a prefered method to do the following task :
Purge then Prune (I'm on auto-prune) then Truncate a volume for a client ?
There are "best practice" for optimal volume management when you use filesystem based volumes:
- use 1 job / volume
That is a good Idea ! I noted it :)
- use action on purge = truncate
Already activated.
But is your volumes truncated by a purge command? Have you got in your logs something like this:
05-Jun 23:05 mars-dir JobId 0: 3307 Issuing autochanger "unload slot 20, drive 0" command.
05-Jun 23:05 mars-dir JobId 0: 3304 Issuing autochanger "load slot 35, drive 0" command.
05-Jun 23:05 mars-dir JobId 0: 3305 Autochanger "load slot 35, drive 0", status is OK.
05-Jun 23:05 mars-dir JobId 0: 3000 OK label. VolBytes=187 DVD=0 Volume="00023" Device="FileStorageDrv0" (/bacula/tapes/drive0)
05-Jun 23:05 mars-dir JobId 0: The volume "00023" has been truncated
- adjust your retention policy and backup schedule (more Incr, less Full)
That's why we have to rethink all the stategy.
Check BaseJobs feature. It provides file level deduplication if proper deployed.
- use compression on client if you have enough computing power
We have, around 80-90% data reduction.
Great...
- use filesystem level compression on storage daemon
I don't know about it ? What's that ?
If you use ZFS or btrfs (i believe others fs can do compression too) you can enable block level transparent compression. These filesystems provides a block level deduplication too, but current Bacula volume format limit fs deduplication usage.
Remember, if you perform a data compression on client do not enable fs compression on storage daemon.
