Re: [bareos-users] Looking for recommendations where to store the bsr and the BackupCatalog file on single tape server

2020-05-18 Thread 'DUCARROZ Birgit' via bareos-users

Thank you Brock Palen and spadaj!
This helps me a lot!

Kind regards,
Birgit
On 17/05/20 23:33, Brock Palen wrote:

Similar here, I have used Bareos/Bacula for over 10 years, many restores, etc.  
Added a single tape drive when switched to Bareos and  client initiated 
connections and easy encryption let me backup a lot more desktops for roaming 
people.

Over that time I still dont’ quite understand when BSR’s come into play and 
have never used one though I still write them to my local drive.  I do not back 
them up to tape.

As for Catalog,  it’s backed up to it’s own Pool on disk, but an Run Script 
then takes the volume and pushes it to a cloud provider with rclone.  It along 
with all the crypto information etc.   This way I can run a bscan etc. and 
recreate the catalog if needed in true DR.
I also changed around the catalog backup script it still just dumps to a text 
file and backs that text file up.  So fi the DB is just corrupted (on a 
different disk) I have a SQL dump on the Director  I can just import.  If I 
need to go further back I have the volumes (that only allow one job)  on the 
cloud I can download and run bscan on.  Etc.

But yeah BSR’s  still not sure what they are used for.

With tape if your using application managed encryption be very sure to backup 
your configs with your encryption information.  That key is used with the key 
in the Catalog to decrypt (if I reading the docs right).  So if you think your 
backing up your Director for DR and planning on using bscan you wont’ be able 
to because you wont’ have the key.

I keep that key (along with the creds for the cloud provider with the catalog 
backups)  in multiple places.  You cannot lose those encryption keys.  Same 
applies to on disk encryption but I have not bothered with that only tape 
encryption.


Brock Palen
1 (989) 277-6075
bro...@mlds-networks.com
www.mlds-networks.com
Websites, Linux, Hosting, Joomla, Consulting




On May 16, 2020, at 4:27 PM, spadaj  wrote:

You don't have to back up bsr files. True, they can be written after backup job 
but they are also created for a restore job based on a file selection, 
timerange selection and so on from the data stored in catalog. So the bsr files 
are not necessary to back up as far as I know.
Another thing is the database backup. It's possible to import a media without 
prior information in catalog but it requires reading of the whole tape. And if 
you're not sure where is your database stored, you'd have to rescan several 
tapes which would be quite time-consuming.
So it's IMO a good practice to have configuration backup (including crypto 
material!) and catalog database backup available on a easily accessible media 
(i.e. dumped onto a some directory NFS-exported from another server). This way 
in case of a disaster you can easily restore your bareos installation by simply 
reinstalling software, restoring config files and loading database from dump.
It's also worth noting that archiving is a different process than backup. Sure, 
you can use bareos for it but archiving process objectives are different than 
backup. There is also hugely different time span that you need to provide data 
availability for so you'd have to architect your solution accordingly. YMMV but 
I'd try to go for more incremental approach to copying data to tape but also 
focused on having multiple copies of every instance of data (possibly at least 
three).

Best regards
MK

W dniu 16.05.2020 o 21:27, 'DUCARROZ Birgit' via bareos-users pisze:

I'm a total newbe in tape backup.
I wonder which is the best practice to store the bsr files and where to backup 
the Catalog on a server with a single tape drive.
Would this be on the tape itself or somewhere on a HD / mount on the server?
If I backup the Catalog on the tape after each backup, how easy would be a 
restore?
Assuming you have archive drives which you will store for 10 years and 
afterwards you install a new backup server, will you be able to re-read these 
drives if the Catalog is directly on the tape or will this only be possible if 
you migrated all the database on the new server?
How do you manage this?
I thought on the following concept (please tell me what you think about that):
- for the database files, all bsr files and the Catalog Backup I tought to 
mount an external share, which will be easy to migrate from one to another 
bareos server.
- Tapes just for the volumes.
Thank you in advance for some hints.
Regards,
Birgit


--
You received this message because you are subscribed to the Google Groups 
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to bareos-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/bareos-users/cd5bacb1-1bd1-4dff-f483-b4c1e319121b%40gmail.com.




--
You received this message because you are subscribed to the Google Groups 
"bareos-users" group.
To unsubscribe from this group and stop receiving 

Re: [bareos-users] Looking for recommendations where to store the bsr and the BackupCatalog file on single tape server

2020-05-16 Thread spadaj
You don't have to back up bsr files. True, they can be written after 
backup job but they are also created for a restore job based on a file 
selection, timerange selection and so on from the data stored in 
catalog. So the bsr files are not necessary to back up as far as I know.
Another thing is the database backup. It's possible to import a media 
without prior information in catalog but it requires reading of the 
whole tape. And if you're not sure where is your database stored, you'd 
have to rescan several tapes which would be quite time-consuming.
So it's IMO a good practice to have configuration backup (including 
crypto material!) and catalog database backup available on a easily 
accessible media (i.e. dumped onto a some directory NFS-exported from 
another server). This way in case of a disaster you can easily restore 
your bareos installation by simply reinstalling software, restoring 
config files and loading database from dump.
It's also worth noting that archiving is a different process than 
backup. Sure, you can use bareos for it but archiving process objectives 
are different than backup. There is also hugely different time span that 
you need to provide data availability for so you'd have to architect 
your solution accordingly. YMMV but I'd try to go for more incremental 
approach to copying data to tape but also focused on having multiple 
copies of every instance of data (possibly at least three).


Best regards
MK

W dniu 16.05.2020 o 21:27, 'DUCARROZ Birgit' via bareos-users pisze:

I'm a total newbe in tape backup.

I wonder which is the best practice to store the bsr files and where to 
backup the Catalog on a server with a single tape drive.


Would this be on the tape itself or somewhere on a HD / mount on the 
server?


If I backup the Catalog on the tape after each backup, how easy would be 
a restore?


Assuming you have archive drives which you will store for 10 years and 
afterwards you install a new backup server, will you be able to re-read 
these drives if the Catalog is directly on the tape or will this only be 
possible if you migrated all the database on the new server?


How do you manage this?

I thought on the following concept (please tell me what you think about 
that):


- for the database files, all bsr files and the Catalog Backup I tought 
to mount an external share, which will be easy to migrate from one to 
another bareos server.

- Tapes just for the volumes.


Thank you in advance for some hints.
Regards,
Birgit





--
You received this message because you are subscribed to the Google Groups 
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to bareos-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/bareos-users/cd5bacb1-1bd1-4dff-f483-b4c1e319121b%40gmail.com.