I'm glad you found a solution.
Can you tell us what issues you found and what the solution was? That might
help someone else in the future.
__Martin
> On Thu, 19 Dec 2024 15:48:55 +0100, Samuel Zaslavsky said:
>
> Hi Martin,
> I managed to get back on my feet: there were several issues th
Hi Martin,
I managed to get back on my feet: there were several issues that made
things difficult to understand, but you helped me a lot.
Thank you so much !
And thanks also to everyone who spent time on my problem !
Best,
Sam
Le ven. 13 déc. 2024 à 19:05, Martin Simmons a
écrit :
> Using 'o' i
Using 'o' in the fileset accurate option has caused problems with restore for
another user on the list recently. I don't know if it could also break
estimate. Have you used the 'o' option in previous incremental backups?
Accurate backups assume that the full path to each file is the same as befo
Hello everyone !
Any ideas for solving this problem?
I'm stuck here...
Thanks a lot for your help,
Best,
Sam
Le ven. 6 déc. 2024 à 12:38, Samuel Zaslavsky a écrit :
> Hello all,
>
> Sorry for this late reply. (According to Murphy's law, our Bacula server
> failed, and it took some time to
Hello all,
Sorry for this late reply. (According to Murphy's law, our Bacula server
failed, and it took some time to figure out that the SAS card was dead, and
get another one ...)
I did some tests, and there's something new :
In fact, the fileset seems to be OK, and the Incremental "could" resu
Hello,
wt., 12 lis 2024 o 12:00 Samuel Zaslavsky napisał(a):
> So, precisely, how does Bacula "decides" a fileset is different from
> another one ?
>
Bacula is checking the fileset changes based on a fileset content.
> Where is this information stored in the database ?
>
It is a fileset tabl
Hi all again and many thanks for your help !
Thanks to you for this answer Robert.
You say : "I am nearly certain that your FD name may be different than
originally specified on your first bacula configuration."
The name hasn't changed : I took it back from the database (in the
fileset.fileset fi
A fileset in bacula does not have to be specific to one job. I understand
that in your case it is specific to one or more jobs, and one server in
particular, but it doesn't have to be job specific. For example you could
back up many systems with one fileset if you only wanted to back up the
same fi
Hi Martin, hi all
Thanks a lot for your answers !
Here's what I can get for one job "BackupARCHIVES" (21 To of datas... the
small one :)
*estimate level=incremental job=BackupARCHIVES
Using Catalog "MyCatalog"
Connecting to Client lto8-fd at localhost:9102
2000 OK estimate files=474,483 bytes=21
On 11/8/24 08:44, Samuel Zaslavsky wrote:
Hello everyone,
I have a job backing up several hundreds of To.
Job is incremental, every week, so only hundreds of Go, or a few To
every week.
After bad manipulation ( I know, I know...), we lost the bacula
configurations (jobs, fileset, etc.) _but no
I had a scenario sort of like this. My backup environment involves a bacula
FD running on a server and that server connects to a NAS appliance via SMB.
This is the only access I have to that NAS appliance, so I cannot run an FD
locally on the appliance.
I ran into some system issues in my original
Just to be sure, are you setting level=Incremental in the estimate command?
Are there any messages in bconsole after running the estimate command (use the
messages command to check)? In particular, look for "The FileSet ... was
modified on ..." or "No prior or suitable Full backup found..."
Did
On 11/8/24 6:44 AM, Samuel Zaslavsky wrote:
Hello everyone,
I have a job backing up several hundreds of To.
Job is incremental, every week, so only hundreds of Go, or a few To every week.
After bad manipulation ( I know, I know...), we lost the bacula configurations
(jobs, fileset, etc.) _but n
13 matches
Mail list logo
