Bacula restores and backups

[tqz]

Hello all

Lets say in the event that disaster strikes and all data on my server is lost for whatever reason. I have encrypted backups of the data on the server stored on tapes (on and off site) and NAS.

After reinstalling my database management system, and then firing up bacula using copies I have of the director, client and storage daemon files how can I then read the catalog from the encrypted tape. Is there any way I can test this without overwriting the bacula database. Also is there a way to read files (the director, storage and daemon) off the encrypted storage and then restoring them using bacula command line tools or non bacula command line tools….or am I not making any sense?!…

Second thing is that I am noticing that the size of the backups on my different storage devices are different. So for example the first backup occurs on the tape and the size of the backup is 14.09gb, then on my second storage device it will be 14.12gb and my third one is 14.16gb. They are all full backups ??? Any idea why there may be different sizes....

Thanks for any help in advance!!!

[Irithori]

I do not use encryption, but just to be precise: the FD does the encryption, not the SD.

SD encryption is a future feature.
SourceForge - bacula/blob - bacula/projects


The scenario you describe:
"Rebuilding the bacula DB with just the config and a crypted dump on a tape."

In short: Not possible.
Volume Utility Tools
Point 2: It cannot restore encrypted files.


Is it really neccessary?
If you need the backups encrypted, ok.
But leave the "selfbackup" unencrypted.

So if the DB breaks unrecoverable, the plan looks like this
- build another server
- install bacula packages
- place config there
- install DB packages
- bextract the dump
- restore the DB dump
- done

In a worst case scenario (DB fubar) you want to have easy procedures.


The Selfbackup job:
A "ClientBeforeJob" script is triggered, that
1) dumps the DB
2) copies the dump to another raid (Two raids would have to break, before I need to bextract from tape)

The Job then includes
a) bacula config
b) bootstrap files
c) the original DB dump

btw:
This job is the only one, that runs during the day and sends an email for succeeded jobs. (Others report only failed jobs)
That way, I have
- one more feedback, that bacula is still alive (apart from monitoring)
- the name of the tape used for that job




About: "Is there any way I can test this without overwriting the bacula database. "
Sure.
Just set up a empty DB "bacula_restoretest" and modify bacula-dir to point to it.
After going through the restore procedures and filling the DB,
it is safe to run restore jobs, imho.

Just dont run backup jobs.
This would increase the filecounter on the tapes.
And if you switch back to the original DB, the tapes will then be marked Error because of the changed filecounter.


I cannot explain the increasing size of the jobs.
Are these CopyJobs?
Are these Jobs of the same client, but with different SDs?

[tqz]

Hello Irithori

Firstly thank you very much for your response and help!

Am I understanding correctly that you cannot restore files from an encrypted tape if the server dies/gets stolen, even if you have the bacula config files, and the keys used for encryption stored in a safe place (unencrypted) using the bacula volume utility tools?

So is there any point to the encryption??? As if anything goes wrong i.e. all our unencrypted data on our NAS goes as well as on the server (worst case scenerio - lets say they all got stolen or gets destroyed in a fire or something), the offsite copy of data stored on tape would be no use to us??? The reason for encryption is mainly for that offsite copy of the tape - to make sure that if it gets lost/stolen none of the classified/personal information can be read.

As for the differing file sizes they are not copy jobs. They are backups of the same client (including the same filesets) but on different SDs. One is a tape, the other two are two NAS. I am now using Rsync to do the backups on the NAS rather than bacula, so this isnt an issue any more but thank you for all your help and advice - it really is appreciated!

Thanks for letting me know how to test out the backup/restore scenerio as well!

t.

[Irithori]

Am I understanding correctly that you cannot restore files from an encrypted tape if the server dies/gets stolen, even if you have the bacula config files, and the keys used for encryption stored in a safe place (unencrypted) using the bacula volume utility tools?

Yes, you understood correct.
With only the bacula volume utility tools, you cannot restore encrypted files.
If you would add the DB dump to your list of unencrypted, off-site files, everything is peachy.
- config files
- keys
- DB dump

So is there any point to the encryption??? As if anything goes wrong i.e. all our unencrypted data on our NAS goes as well as on the server (worst case scenerio - lets say they all got stolen or gets destroyed in a fire or something), the offsite copy of data stored on tape would be no use to us???

Robbery:
I have a little trouble following your logic.
Are you telling me, the datacenter where the production servers and the backup server presumably are, is a hostile and dangerous place?
No access controll, everyone could just walk in and take the backup server?

Then what is stopping this person to take the production servers?
Would be even easier to get the data from there.

If you encrypt the backups to be secured in a case of theft _at_the_datacenter_,
then -in consequence- you would have to encrypt the filesystems of _all_ production servers.
I am quite sure, (at least) your database administrators will kill you, if you suggest that


Fire:
Like I said in the first paragraph:
Make sure you have an up-to-date DB dump. Unencrypted.
There are several ways to do that.
- let the RunBeforeScript of the Selfbackupjob do an scp of the DB dump to somewhere Off-Site.
- leave that Selfbackup job unencrypted, so you can use bextract.
All the other jobs can be encrypted, if you like. (please handle this statement with care, I didnt actually test this scenario)



Imho, there are at least two cases that can be handled by encryption.

Case 1) the FD (or better: the person operating this client computer) doesnt trust the DIR.
Then the files can only be restored to _this_ particular client.
This is a weak argument, as the FD is a pretty good "trojan" (execute, read/write files as root/administrator)
and can be controlled by the DIR.

Case 2) you need to send tapes over unsecure channels.
Say, you make encrypted backups to tapes. Then you want to pack them in boxes and ship them to another city.
The boxes get stolen -> You only loose the money for the tapes, but the data is secure.

The reason for encryption is mainly for that offsite copy of the tape - to make sure that if it gets lost/stolen none of the classified/personal information can be read.

This setup is supposed to be a permanent solution, right?

So -in my mind- the same principle apply to that Off-Site location as it does to the datacenter.
Lock the door. Only authorized access. Security personel. Let the Off-Site location be another datacenter.
Whatever can be justified by the value of your data.


If both DC and OffSite would be secure places, you migh be able to drop the idea of encrypted tapes completly?
Following the KISS principle. KISS principle - Wikipedia, the free encyclopedia

Is the connection between DC and offSite secure?
If not: Bacula TLS -- Communications Encryption

As for the differing file sizes they are not copy jobs. They are backups of the same client (including the same filesets) but on different SDs. One is a tape, the other two are two NAS.

A simple answer could be:
As the jobs run one after the other, maybe a few files grew larger in the meantime? logfiles, accesslogfiles,...

I am now using Rsync to do the backups on the NAS rather than bacula, so this isnt an issue any more

Two different tools for the same purpose are usually a sign of bad design

thank you for all your help and advice - it really is appreciated!

Your welcome