Re: [Bacula-users] Discrepancy between backup/restore size and files
Hello, śr., 30 wrz 2020 o 12:33 Ben Laurie napisał(a): > > > On Wed, 30 Sep 2020 at 09:42, Radosław Korzeniewski < > rados...@korzeniewski.net> wrote: > >> Hello, >> >> pon., 28 wrz 2020 o 14:34 Ben Laurie napisał(a): >> >>> >>> >>> On Sun, 13 Sep 2020 at 18:58, Josip Deanovic >>> wrote: >>> On Sunday 2020-09-13 15:43:31 Ben Laurie wrote: > > Not sure if IgnoreCase option could caused it somehow. > > According to the documentation it just makes it ignore case for pattern > matching, so seems unlikely? I can't say because I didn't use Bacula with Windows a lot. It worked fine back in 2010-2012. > Yes, funny I somehow had not noticed that before - I've added it. I > presume it won't fix this problem, tho. No, but it will make the difference for future backups. >>> >>> I tried using accurate but it just caused errors (I forget what now, but >>> some problem with database searches?). >>> >>> In other news, I did a full restore as a test recently and I got quite a >>> few errors along the lines of: >>> >>> 25-Sep 14:46 xxx-fd JobId 35: Error: File /tmp/bacula-restores/k/xxx >>> already exists and could not be replaced. ERR=Permission denied. >>> >> >> First of all to properly restore Windows files on any Linux or Unix >> machine you have to set a Portable flag for your backup. >> > > According to > https://www.bacula.org/5.1.x-manuals/fr/main/main/Windows_Version_Bacula.html > that is no longer true... > > "Note: with Bacula versions 1.39.x and later, non-portable Windows data > can be restore to any machine." > Not exactly. You can restore some data because non windows file daemon accept windows stream. And this is what the above statement means. But this stream is what win32 BackupRead() generates. It could be the same bit2bit what standard read() can generate but there is no guarantee. The Portable flag replaces win32 BackupRead() for a simple read(). best regards -- Radosław Korzeniewski rados...@korzeniewski.net ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Discrepancy between backup/restore size and files
On Wed, 30 Sep 2020 at 09:42, Radosław Korzeniewski < rados...@korzeniewski.net> wrote: > Hello, > > pon., 28 wrz 2020 o 14:34 Ben Laurie napisał(a): > >> >> >> On Sun, 13 Sep 2020 at 18:58, Josip Deanovic >> wrote: >> >>> On Sunday 2020-09-13 15:43:31 Ben Laurie wrote: >>> > > Not sure if IgnoreCase option could caused it somehow. >>> > >>> > According to the documentation it just makes it ignore case for pattern >>> > matching, so seems unlikely? >>> >>> I can't say because I didn't use Bacula with Windows a lot. >>> It worked fine back in 2010-2012. >>> >>> > Yes, funny I somehow had not noticed that before - I've added it. I >>> > presume it won't fix this problem, tho. >>> >>> No, but it will make the difference for future backups. >>> >> >> I tried using accurate but it just caused errors (I forget what now, but >> some problem with database searches?). >> >> In other news, I did a full restore as a test recently and I got quite a >> few errors along the lines of: >> >> 25-Sep 14:46 xxx-fd JobId 35: Error: File /tmp/bacula-restores/k/xxx >> already exists and could not be replaced. ERR=Permission denied. >> > > First of all to properly restore Windows files on any Linux or Unix > machine you have to set a Portable flag for your backup. > According to https://www.bacula.org/5.1.x-manuals/fr/main/main/Windows_Version_Bacula.html that is no longer true... "Note: with Bacula versions 1.39.x and later, non-portable Windows data can be restore to any machine." With Portable=no (which is a default) Bacula will backup Windows files > using Windows API calls which are not strictly portable to Linux/Unix > read/write. This could explain the backup/restore sizes. > Additionally above "Permission denied" errors are extremely strange and > could directly influence your restore. This could additionally explain the > backup/restore sizes. > > best regards > -- > Radosław Korzeniewski > rados...@korzeniewski.net > ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Discrepancy between backup/restore size and files
Hello, pon., 28 wrz 2020 o 14:34 Ben Laurie napisał(a): > > > On Sun, 13 Sep 2020 at 18:58, Josip Deanovic > wrote: > >> On Sunday 2020-09-13 15:43:31 Ben Laurie wrote: >> > > Not sure if IgnoreCase option could caused it somehow. >> > >> > According to the documentation it just makes it ignore case for pattern >> > matching, so seems unlikely? >> >> I can't say because I didn't use Bacula with Windows a lot. >> It worked fine back in 2010-2012. >> >> > Yes, funny I somehow had not noticed that before - I've added it. I >> > presume it won't fix this problem, tho. >> >> No, but it will make the difference for future backups. >> > > I tried using accurate but it just caused errors (I forget what now, but > some problem with database searches?). > > In other news, I did a full restore as a test recently and I got quite a > few errors along the lines of: > > 25-Sep 14:46 xxx-fd JobId 35: Error: File /tmp/bacula-restores/k/xxx > already exists and could not be replaced. ERR=Permission denied. > First of all to properly restore Windows files on any Linux or Unix machine you have to set a Portable flag for your backup. With Portable=no (which is a default) Bacula will backup Windows files using Windows API calls which are not strictly portable to Linux/Unix read/write. This could explain the backup/restore sizes. Additionally above "Permission denied" errors are extremely strange and could directly influence your restore. This could additionally explain the backup/restore sizes. best regards -- Radosław Korzeniewski rados...@korzeniewski.net ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Discrepancy between backup/restore size and files
On Sun, 13 Sep 2020 at 18:58, Josip Deanovic wrote: > On Sunday 2020-09-13 15:43:31 Ben Laurie wrote: > > > Not sure if IgnoreCase option could caused it somehow. > > > > According to the documentation it just makes it ignore case for pattern > > matching, so seems unlikely? > > I can't say because I didn't use Bacula with Windows a lot. > It worked fine back in 2010-2012. > > > Yes, funny I somehow had not noticed that before - I've added it. I > > presume it won't fix this problem, tho. > > No, but it will make the difference for future backups. > I tried using accurate but it just caused errors (I forget what now, but some problem with database searches?). In other news, I did a full restore as a test recently and I got quite a few errors along the lines of: 25-Sep 14:46 xxx-fd JobId 35: Error: File /tmp/bacula-restores/k/xxx already exists and could not be replaced. ERR=Permission denied. As an aside, I accidentally did the restore to the Windows machine and it set the top level directories to system, hidden so it was really hard to even see the restored backup! Also, the reported size was considerably smaller than the size of a full backup. -- > Josip Deanovic > > > ___ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Discrepancy between backup/restore size and files
On Mon, 14 Sep 2020 at 01:53, Dan Langille wrote: > On Sat, Sep 12, 2020, at 6:23 AM, Ben Laurie wrote: > > I restored a Windows incremenental backup (to a FreeBSD machine). > > The restore job looks like: > > Build OS: amd64-portbld-freebsd12.1 freebsd 12.1-SYNTH > JobId: 92 > Job:RestoreFiles.2020-09-12_10.36.22_08 > Restore Client: b2-fd > Where: /tmp/bacula-restores > Replace:Always > Start time: 12-Sep-2020 10:36:24 > End time: 12-Sep-2020 10:45:48 > Elapsed time: 9 mins 24 secs > Files Expected: 3,858 > Files Restored: 3,858 > Bytes Restored: 82,256,949,051 (82.25 GB) > Rate: 145845.7 KB/s > FD Errors: 0 > FD termination status: OK > SD termination status: OK > Termination:Restore OK > > But... > > b2 /tmp/bacula-restores# du -sh * > 804Mc: > 22Kj: > 25Gk: > > Why are the restored files less than a third of the size of the restore > job? > > > Is zfs compression involved? > Hmm. I thought du reported the size in blocks of the files, rather than what they actually take on disk? If you look at https://github.com/coreutils/coreutils/blob/master/src/du.c#L589 (the first du I found) that suggests it is just using the file size as returned by stat(). > > -- > Dan Langille > d...@langille.org > > > ___ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Discrepancy between backup/restore size and files
On Sunday 2020-09-13 20:29:17 Dan Langille wrote: > On Sat, Sep 12, 2020, at 6:23 AM, Ben Laurie wrote: > > Why are the restored files less than a third of the size of the > > restore job? > Is zfs compression involved? Hmm... du command on FreeBSD has -A option which will probably work. GNU du has --apparent-size -- Josip Deanovic ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Discrepancy between backup/restore size and files
On Sat, Sep 12, 2020, at 6:23 AM, Ben Laurie wrote: > I restored a Windows incremenental backup (to a FreeBSD machine). > > The restore job looks like: > > Build OS: amd64-portbld-freebsd12.1 freebsd 12.1-SYNTH > JobId: 92 > Job:RestoreFiles.2020-09-12_10.36.22_08 > Restore Client: b2-fd > Where: /tmp/bacula-restores > Replace:Always > Start time: 12-Sep-2020 10:36:24 > End time: 12-Sep-2020 10:45:48 > Elapsed time: 9 mins 24 secs > Files Expected: 3,858 > Files Restored: 3,858 > Bytes Restored: 82,256,949,051 (82.25 GB) > Rate: 145845.7 KB/s > FD Errors: 0 > FD termination status: OK > SD termination status: OK > Termination:Restore OK > > But... > > b2 /tmp/bacula-restores# du -sh * > 804Mc: > 22Kj: > 25Gk: > > Why are the restored files less than a third of the size of the restore job? Is zfs compression involved? -- Dan Langille d...@langille.org ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Discrepancy between backup/restore size and files
On Sunday 2020-09-13 15:43:31 Ben Laurie wrote: > > Not sure if IgnoreCase option could caused it somehow. > > According to the documentation it just makes it ignore case for pattern > matching, so seems unlikely? I can't say because I didn't use Bacula with Windows a lot. It worked fine back in 2010-2012. > Yes, funny I somehow had not noticed that before - I've added it. I > presume it won't fix this problem, tho. No, but it will make the difference for future backups. -- Josip Deanovic ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Discrepancy between backup/restore size and files
On Sun, 13 Sep 2020 at 13:20, Josip Deanovic wrote: > On Saturday 2020-09-12 18:08:41 Ben Laurie wrote: > > Hmmm! > > > > # find . | wc -l > > 4422 > > # find . -type f | wc > > 32868013 360780 > > # find . -not -type d | wc > > 32868013 360780 > > Interesting. > > Do you get the output you would expect when you avoid piping it to > the wc command? > Yeah. I started doing a comparison line by line to the Bacula listing. I didn't finish, it got quite boring - might have to write some code! But all I found was: 1. Bacula not listing some directories, but only if it did list something in a subdirectory. 2. I found one file that Bacula listed but wasn't restored - I can't remember what it was called but the name suggested it was a lock file, which is why I thought it might be a deleted file. > > On closer inspection there are complications... > > > > 1. Bacula doesn't seem to have entries for all directories, even if it > > has stored files in them. But it does have some. > > Not sure if IgnoreCase option could caused it somehow. According to the documentation it just makes it ignore case for pattern matching, so seems unlikely? > > > 2. Presumably, since this is an incremental dump, it will include files > > that have been deleted, but seems you can't tell from "list files > > jobid=xxx". > > There is an "Accurate" option that can be used in Job resource. > > In short, it says: "In accurate mode, the File daemon knowns exactly which > files were present after the last backup. So it is able to handle deleted > or renamed files." > > This option requires a bit more memory on the client side but I would say > it is worth it. > Yes, funny I somehow had not noticed that before - I've added it. I presume it won't fix this problem, tho. > > > -- > Josip Deanovic > > > ___ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Discrepancy between backup/restore size and files
On Saturday 2020-09-12 18:08:41 Ben Laurie wrote: > Hmmm! > > # find . | wc -l > 4422 > # find . -type f | wc > 32868013 360780 > # find . -not -type d | wc > 32868013 360780 Interesting. Do you get the output you would expect when you avoid piping it to the wc command? > On closer inspection there are complications... > > 1. Bacula doesn't seem to have entries for all directories, even if it > has stored files in them. But it does have some. Not sure if IgnoreCase option could caused it somehow. > 2. Presumably, since this is an incremental dump, it will include files > that have been deleted, but seems you can't tell from "list files > jobid=xxx". There is an "Accurate" option that can be used in Job resource. In short, it says: "In accurate mode, the File daemon knowns exactly which files were present after the last backup. So it is able to handle deleted or renamed files." This option requires a bit more memory on the client side but I would say it is worth it. -- Josip Deanovic ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Discrepancy between backup/restore size and files
On Sat, 12 Sep 2020 at 14:16, Josip Deanovic wrote: > On Saturday 2020-09-12 09:27:51 Heitor Faria wrote: > > Hello Ben, > > > > Perhaps you could check the difference between the "list files jobid=xx" > > and the list of restored files? > > Good idea but he already got the number of files when the restore > job completed: > > Files Expected: 3,858 > Files Restored: 3,858 > > So a quick check of the number of restored files might be useful. > Something like: find /tmp/bacula-restores -print | wc -l > Hmmm! # find . | wc -l 4422 # find . -type f | wc 32868013 360780 # find . -not -type d | wc 32868013 360780 On closer inspection there are complications... 1. Bacula doesn't seem to have entries for all directories, even if it has stored files in them. But it does have some. 2. Presumably, since this is an incremental dump, it will include files that have been deleted, but seems you can't tell from "list files jobid=xxx". > Should be executed as root. > > > My guess is that the number will match. > > -- > Josip Deanovic > > > ___ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Discrepancy between backup/restore size and files
On Sat, 12 Sep 2020 at 13:37, Josip Deanovic wrote: > On Saturday 2020-09-12 12:18:05 Ben Laurie wrote: > > Hmmm. > > > > I don't think I have that problem... > [...] > > > What about: > > File = c:/ <- this > File = j:/ > File = k:/ > File = c:/Users/camil/OneDrive <- and this one? > This is a different mountpoint.. Also: # du -sh c:/Users/camil/OneDrive 15Kc:/Users/camil/OneDrive > > > Could the size of the c:/Users/camil/OneDrive directory be the > missing kilobytes you are looking for? > > -- > Josip Deanovic > > > ___ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Discrepancy between backup/restore size and files
On Saturday 2020-09-12 09:27:51 Heitor Faria wrote: > Hello Ben, > > Perhaps you could check the difference between the "list files jobid=xx" > and the list of restored files? Good idea but he already got the number of files when the restore job completed: Files Expected: 3,858 Files Restored: 3,858 So a quick check of the number of restored files might be useful. Something like: find /tmp/bacula-restores -print | wc -l Should be executed as root. My guess is that the number will match. -- Josip Deanovic ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Discrepancy between backup/restore size and files
Hello Ben,
Perhaps you could check the difference between the "list files jobid=xx" and
the list of restored files?
Rgds.
--
MSc Heitor Faria
CEO Bacula LatAm
mobile1: + 1 909 655-8971
mobile2: + 55 61 98268-4220
América Latina
[ http://bacula.lat/]
Original Message
From: Ben Laurie
Sent: Saturday, September 12, 2020 07:23 AM
To: Josip Deanovic
Subject: Re: [Bacula-users] Discrepancy between backup/restore size and files
CC: Bacula Users
>Hmmm.
>
>I don't think I have that problem...
>
>FileSet {
> Name = "Full Set xxx.home"
> Enable VSS = yes
> Include {
>Options {
> signature = SHA1
> IgnoreCase = yes
> # Remove cruft
>
> Exclude = yes
> # Swap files
>
> WildFile = "[A-Z]:/pagefile.sys"
> WildFile = "[A-Z]:/hiberfil.sys"
> WildFile = "[A-Z]:/swapfile.sys"
> # Stuff that churns a lot but isn't really useful (assuming we fix
>death \
>by creating a new Windows machine and restoring data files only)
>
> # Where windows keeps all its DLLs and stuff, seems to get updated a
>lot,\
> and not really useful...
>
> WildDir = "c:/Windows/WinSxS"
> WildDir = "c:/Windows/SoftwareDistribution"
> WildDir = "c:/Windows/Prefetch"
> # Who knows?
>
> WildDir = "c:/Windows/assembly"
> # Antivirus
>
> WildDir = "c:/ProgramData/Microsoft/Windows Defender"
> # Stuff that has errors (and is no longer used)
>
> WildDir = "j:/Windows"
>}
>File = c:/
>File = j:/
>File = k:/
>File = c:/Users/camil/OneDrive
> }
>}
>
>On Sat, 12 Sep 2020 at 12:03, Josip Deanovic
>wrote:
>
>> On Saturday 2020-09-12 11:23:25 Ben Laurie wrote:
>> > I restored a Windows incremenental backup (to a FreeBSD machine).
>> >
>> > The restore job looks like:
>> >
>> > Build OS: amd64-portbld-freebsd12.1 freebsd 12.1-SYNTH
>> > JobId: 92
>> > Job:RestoreFiles.2020-09-12_10.36.22_08
>> > Restore Client: b2-fd
>> > Where: /tmp/bacula-restores
>> > Replace:Always
>> > Start time: 12-Sep-2020 10:36:24
>> > End time: 12-Sep-2020 10:45:48
>> > Elapsed time: 9 mins 24 secs
>> > Files Expected: 3,858
>> > Files Restored: 3,858
>> > Bytes Restored: 82,256,949,051 (82.25 GB)
>> > Rate: 145845.7 KB/s
>> > FD Errors: 0
>> > FD termination status: OK
>> > SD termination status: OK
>> > Termination:Restore OK
>> >
>> > But...
>> >
>> > b2 /tmp/bacula-restores# du -sh *
>> > 804Mc:
>> > 22Kj:
>> > 25Gk:
>> >
>> > Why are the restored files less than a third of the size of the restore
>> > job?
>>
>> Hello Ben!
>>
>> I can't be sure for your case but the documentation states:
>>
>> -BEGIN-
>> Take special care not to include a directory twice or Bacula will backup
>> the same files two times wasting a lot of space on your archive device.
>> Including a directory twice is very easy to do. For example:
>>
>> Include {
>> File = /
>> File = /usr
>> Options { compression=GZIP }
>> }
>>
>> on a Unix system where /usr is a subdirectory (rather than a mounted
>> filesystem) will cause /usr to be backed up twice.
>> -END-
>>
>> Could you check the relevant file set?
>>
>> Regards!
>>
>> --
>> Josip Deanovic
>>
>>
>> ___
>> Bacula-users mailing list
>> Bacula-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bacula-users
>>
>
>
>___
>Bacula-users mailing list
>Bacula-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bacula-users
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Discrepancy between backup/restore size and files
On Saturday 2020-09-12 12:18:05 Ben Laurie wrote: > Hmmm. > > I don't think I have that problem... [...] What about: File = c:/ <- this File = j:/ File = k:/ File = c:/Users/camil/OneDrive <- and this one? Could the size of the c:/Users/camil/OneDrive directory be the missing kilobytes you are looking for? -- Josip Deanovic ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Discrepancy between backup/restore size and files
Hmmm.
I don't think I have that problem...
FileSet {
Name = "Full Set xxx.home"
Enable VSS = yes
Include {
Options {
signature = SHA1
IgnoreCase = yes
# Remove cruft
Exclude = yes
# Swap files
WildFile = "[A-Z]:/pagefile.sys"
WildFile = "[A-Z]:/hiberfil.sys"
WildFile = "[A-Z]:/swapfile.sys"
# Stuff that churns a lot but isn't really useful (assuming we fix
death \
by creating a new Windows machine and restoring data files only)
# Where windows keeps all its DLLs and stuff, seems to get updated a
lot,\
and not really useful...
WildDir = "c:/Windows/WinSxS"
WildDir = "c:/Windows/SoftwareDistribution"
WildDir = "c:/Windows/Prefetch"
# Who knows?
WildDir = "c:/Windows/assembly"
# Antivirus
WildDir = "c:/ProgramData/Microsoft/Windows Defender"
# Stuff that has errors (and is no longer used)
WildDir = "j:/Windows"
}
File = c:/
File = j:/
File = k:/
File = c:/Users/camil/OneDrive
}
}
On Sat, 12 Sep 2020 at 12:03, Josip Deanovic
wrote:
> On Saturday 2020-09-12 11:23:25 Ben Laurie wrote:
> > I restored a Windows incremenental backup (to a FreeBSD machine).
> >
> > The restore job looks like:
> >
> > Build OS: amd64-portbld-freebsd12.1 freebsd 12.1-SYNTH
> > JobId: 92
> > Job:RestoreFiles.2020-09-12_10.36.22_08
> > Restore Client: b2-fd
> > Where: /tmp/bacula-restores
> > Replace:Always
> > Start time: 12-Sep-2020 10:36:24
> > End time: 12-Sep-2020 10:45:48
> > Elapsed time: 9 mins 24 secs
> > Files Expected: 3,858
> > Files Restored: 3,858
> > Bytes Restored: 82,256,949,051 (82.25 GB)
> > Rate: 145845.7 KB/s
> > FD Errors: 0
> > FD termination status: OK
> > SD termination status: OK
> > Termination:Restore OK
> >
> > But...
> >
> > b2 /tmp/bacula-restores# du -sh *
> > 804Mc:
> > 22Kj:
> > 25Gk:
> >
> > Why are the restored files less than a third of the size of the restore
> > job?
>
> Hello Ben!
>
> I can't be sure for your case but the documentation states:
>
> -BEGIN-
> Take special care not to include a directory twice or Bacula will backup
> the same files two times wasting a lot of space on your archive device.
> Including a directory twice is very easy to do. For example:
>
> Include {
> File = /
> File = /usr
> Options { compression=GZIP }
> }
>
> on a Unix system where /usr is a subdirectory (rather than a mounted
> filesystem) will cause /usr to be backed up twice.
> -END-
>
> Could you check the relevant file set?
>
> Regards!
>
> --
> Josip Deanovic
>
>
> ___
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Discrepancy between backup/restore size and files
On Saturday 2020-09-12 11:23:25 Ben Laurie wrote:
> I restored a Windows incremenental backup (to a FreeBSD machine).
>
> The restore job looks like:
>
> Build OS: amd64-portbld-freebsd12.1 freebsd 12.1-SYNTH
> JobId: 92
> Job:RestoreFiles.2020-09-12_10.36.22_08
> Restore Client: b2-fd
> Where: /tmp/bacula-restores
> Replace:Always
> Start time: 12-Sep-2020 10:36:24
> End time: 12-Sep-2020 10:45:48
> Elapsed time: 9 mins 24 secs
> Files Expected: 3,858
> Files Restored: 3,858
> Bytes Restored: 82,256,949,051 (82.25 GB)
> Rate: 145845.7 KB/s
> FD Errors: 0
> FD termination status: OK
> SD termination status: OK
> Termination:Restore OK
>
> But...
>
> b2 /tmp/bacula-restores# du -sh *
> 804Mc:
> 22Kj:
> 25Gk:
>
> Why are the restored files less than a third of the size of the restore
> job?
Hello Ben!
I can't be sure for your case but the documentation states:
-BEGIN-
Take special care not to include a directory twice or Bacula will backup
the same files two times wasting a lot of space on your archive device.
Including a directory twice is very easy to do. For example:
Include {
File = /
File = /usr
Options { compression=GZIP }
}
on a Unix system where /usr is a subdirectory (rather than a mounted
filesystem) will cause /usr to be backed up twice.
-END-
Could you check the relevant file set?
Regards!
--
Josip Deanovic
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
