I have been asked to support a Linux environment running Bacula on an emergency basis. Bacula version is 3.0.1. I only have access to bconsole - no guis. I am also completely brand new to Bacula as of a couple of hours ago. I have no physical access to this server.

Basically, I need to determine how to massively reduce the Bacula disk footprint (physical space the disk-based volume files are using) without adding more data to disk.

This client has a Bacula server with 1.3+ TB of internal disk. It is completely full. I used a 'tune2fs -m 1' to give me back some of the reserved space for actual use and "breathing room". All Bacula data is written to a group of 70 files, each roughly 10 GB a piece. Reducing this footprint would help reduce the filesystem from being 100% full.

There are 23 backup clients. I have set the File Retention on all jobs down to 21 days. (Was 60 days). I have set the Job Retention on all jobs down to 2 months (was 6 months.)

I would like to know, using bconsole commands only, the correct steps that will result in fewer physical volume files (hence reduced disk usage) without corrupting any of the data in place. I have a hunch it is some combination of prune commands, followed by purges? I just don't know, and want to proceed safely.

All advice much appreciated.

Please, no:
- Criticizing of the setup - it wasn't mine
- Suggestions that require anything complex outside of bconsole
- Vague descriptions that don't point me to specific steps
- Steps which require more than a couple GB of free disk space

Thanks!!

I'm going to offer something that's not a "vague description", but rather a reality check.

In an emergency situation like this, it's crucial to avoid causing a second harmful event (which is normally more damaging than the initial problem).

That said, there is a methodical approach for getting on track:

1. Set up an impromptu test system with the same Bacula version installed
2. Read the documentation on Bacula Console commands, and experiment in your test environment to confirm they do what you'd expect
3. Document the precise steps needed (and how you arrived at that conclusion), inform the customer you're proceeding (and the potential risks involved), and then do it in production.

This reduces your own risks, and makes a favorable outcome much, much more likely. It also provides a trail showing you did your due diligence if you manage to muck things up in spite of it all.

Anything short of that careful approach - including following specific technical advice from a stranger on a forum - and you're really sticking your neck out.

1 members found this post helpful.

I'd add:

If you're not able to figure out the required steps by reading the Bacula Console documentation, try pinging their user mailing list. But the same rule applies - test any information you receive carefully before doing it in production.

And give the customers a realistic idea about timeline. My guess is they would prefer to have a system that is working correctly in a day or two over a system that is completely borked in twenty minutes.

Yes -- "make haste slowly". Data is irreplaceable and when things go wrong they can go wrong in the worst of all possible ways. How about getting another HDD, preferably larger than the 1.5 TB which does not seem big enough for the backup needs, and copy all the files across plus everything under the Bacula install directory (recommended /opt/bacula) while the Bacula daemons are not running so you can get back to where you are now if anything goes wrong.

The usual gotcha in this situation is that purging and truncating does not truncate the volume files on disk. For that you need the action=truncate option of the purge command.

Fantastic advice - I appreciate it. I can tell you've got some wisdom under your belt. Before I saw your post I actually did exactly what you suggested and all worked out well.

What I ended up doing was pruning files, then jobs, then each volume, applying the new retention policy I had set. Turns out, after specific volume prunes, it told me it was marking the volume as purged. For about 20 of these volumes, I deleted the volume within bconsole, and then physically removed it from disk.

This freed up the space we needed, and should still leave plenty of physical media to hold 21 days worth of backups.

Thanks again for the advice.

[EDIT]: Apparently the action= directive doesn't work or apply in 3.0.1 - bug?

Normally I'd agree with this but I didn't have physical access to the server and the customer advised me they'd prefer a riskier "more aggresive" approach than carefully waiting 1-2 days to go through the due diligence of preserving the backup environment. (!!! I was surprised too!)

In the end I quintuple-checked everything I was getting from the Bacula documentation along with the modest amount (2-3) of helpful links I could find on the Inter-webs.

Thanks again to everyone for their advice in this thread - very wise indeed.

Sorry -- it was not introduced until a later version.