On 19.05.2020 10:57, Miguel da Silva wrote:
Hello,
I have a massive Bareos Setup and one of my clients (Let's name him
"client1") has had backup errors or slow backups.
So i investigated and found the Problem on client1.
Now i want to remove all old traces of data of client1 from the
database and the actual volumes on the storage.
Since the first storage (600TB) is almost full, i want to regain some
space.
Is there a neat way to get volume names that only have data from
"client1"?
I guess after that i would have to
1. delete the Volumes from The Storage.
2. bconsole > delete volume=volname1
3. somehow clean the database which has also grown now to around 400GB
when dumped.
Help would be much appreciated.
I don't want to make any errors or delete wrong Volumes, since 200
Clients are now being saved and 200 more are coming when the next
storage arrives.
There are two approaches:
1) The bareos way - purge jobs associated with given client and let the
bareos do its job. And that's the approach I'd recommend. Purge jobs
from given client, make sure you have "purge volume action=truncate" set
and the prune all volumes. If volumes are no longer associated with any
jobs (because you purged jobs from a particular client) they get purged.
When they get purged, they are truncated. And voila
2) The manuall fiddling way - you get list of volumes containing only
jobs from a given client by clever sql query (like inner join on
jobmedia and job with a where on particular client and group by media id
and count to select only volumes containing this single client jobs),
then you manually delete volumes and manually delete files from storage.
It can be done but it's not something that I'd recommend since the
previous approach is IMO much safer.
You didn't tell us whether you're using one job per volume setup or any
other settings because that could make your task a little bit easier.
The database issue is another story. Depending on database type (MySQL?
Postgres? I don't suppose you're running this installation on sqlite)
and even database configuration (MySQL table engine and - for example -
file per table settings in case of innodb) you might need to do
different things. Of course dump/restore will give you a "shrinked
database" but that's a very radical approach. You might get away with
vacujming postgres database but keep in mind that for the vacuuming
process you need additional storage temporarily (my database shrunk from
3.3GB to 2.6G after vacuuming but needed over 5G during vacuuming) and
the process itself is time-consuming.
Best regards
MK
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/bareos-users/ff23cb1e-b735-cd4c-87bc-7391033b865f%40gmail.com.
