[Bacula-users] Trouble with Accurate flag
A couple of weeks ago I decided to add the Accurate = yes flag to my backup jobs. I thought it shouldn't do any harm and might make restores more precise. This worked fine until yesterday. Yesterday, all of a sudden, my incremental backups decided to backup ALL EXISTING FILES (and not only the changed ones)! At least they tried to - they ran out of storage, as this was not planned. Luckily, so I noticed the crap. I did check the usual possibilities and didn't find a problem - the timestamps of my files hadn't been tampered with, the fileset description hadn't been modified, and there was no failed full backup in the database which could have triggered a new full backup. Also, the joblog entry looked okay so far: Backup Level: Incremental, since=2012-01-16 09:12:26 FileSet:"SysBack" 2008-02-10 06:46:30 Scheduled time: 17-Jan-2012 09:12:00 I am doing daily Incrementals and this here correctly shows the time from Monday morning to Tuesday morning. I restarted client and server and retried, but still it insisted in saving EVERY file. Then I removed the Accurate flag, and instantly the backup worked as it should! Then I figured - I had run OffSite backups during the night from Monday to Tuesday! My backup scheme is as follows: daily Incremental, monthly Full. And occasionally I run additional Full backups onto tape, to be stored in a remote location. These OffSite backups are using the same Client and Fileset, but different Job. And obviousely they do not write Catalog (fileinfo), because these tapes aren't intended for single-file-restore. Obviousely these full backups, which have no catalog info, are used as the information-source for the Accurate flag! And with no Catalog Info, it looked like there were no files at all contained in the previous backup, and therefore EVERY file would be saved in the Incremental, disregarding timestamps. Understood so far, the solution was simple: I added another Client-stanza with a different name for each machine, and let the OffSite Backups run with that different Client name. I modified the old OffSite jobs in the database to that new Client-id, and now everything seems to behave fine again. Then I checked the manual. The manual says: > In accurate mode, the File daemon knowns exactly which files were > present after the last backup. But it does not say how we define "the last backup". Whereas the "Incremental" Feature clearly defines what is the last backup: > all files specified in the FileSet that have changed since the > last successful backup of the the same Job using the same FileSet > and Client, will be backed up So, obviousely the Accurate Flag uses a different information-source (disregarding the Job name) than the Incremental backup itself. Operating Version here is Client: "Disp" 5.0.3 (04Aug10) i386-portbld-freebsd7.4,freebsd,7.4-STABLE Maybe thats already fixed in newer versions? But at least with this version, this means you cannot rely on the Accurate flag when running different Jobs on the same Client and Fileset; it might loose data. PMc -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] Volume Retention Setting Not Honoured
Hi,
Please can someone offer some insight as to why my volume retention setting
seems to be ignored in the following job log: http://pastebin.com/LWe7D42L ?
As you can see:
3076, 3148, 3211, 3368 are scheduled for copy.
Job 3076 starts to copy.
Volume SVN_Full_Copy_1504 is created and labelled ok.
Job 3076 is copied successfully to SVN_Full_Copy_1504
Job 3148 starts to copy.
SVN_Full_Copy_1504 fills up to MaxVolBytes.
SVN_Full_Copy_1505 is created and labelled.
Job 3148 is copied successfully to SVN_Full_Copy_1504 and SVN_Full_Copy_1505.
Job 3211 starts to copy.
SVN_Full_Copy_1505 fills up to MaxVolBytes.
!! Bacula says that there's no more jobs associated with SVN_Full_Copy_1504 !!
SVN_Full_Copy_1504 is purged (even though it's set to be kept for 6 days)
SVN_Full_Copy_1504 Recycled
Job 3211 is copied successfully to SVN_Full_Copy_1505 and SVN_Full_Copy_1504
Job 3368 starts to copy.
SVN_Full_Copy_1504 fills to MaxVolBytes.
!! Bacula says that there's no more jobs associated with SVN_Full_Copy_1505 !!
SVN_Full_Copy_1505 is purged (again, even though it is set to be kept for 6
days)
SVN_Full_Copy_1505 fills to MaxVolBytes.
SVN_Full_Copy_1506 is created an labelled ok.
SVN_Full_Copy_1506 fills to MaxVolBytes.
SVN_Full_Copy_150is created and labelled successfully.
Job 3368 is copied successfully to SVN_Full_Copy_1504, SVN_Full_Copy_1505,
SVN_Full_Copy_1506 and SVN_Full_Copy_1507.
The result is that I only have a copy of jobs 3211 and 3368, when I should have
3076, 3148, 3211, 3368, which Bacula marked to be copied.
The sections of my config which may be of interest:
bacula-dir.conf
Client {
Name = FileServer1-fd
Address = FileServer1
FDPort = 9102
Catalog = MyCatalog
Password =
File Retention = 4 weeks
Job Retention = 6 months
AutoPrune = yes
}
Job {
Name = "SVN Repositories Full Copy"
JobDefs = DefaultCopy
Type = Copy
Client = FileServer1-fd
FileSet = "SVN Repositories"
Pool = SVN_Full
Messages = Standard
Selection Type = PoolUncopiedJobs
Enabled = No
}
Pool {
Name = "SVN_Full_Copy"
Pool Type = *Copy
Volume Retention = 1 weeks
Recycle = yes
AutoPrune = yes
LabelFormat = SVN_Full_Copy_
Maximum Volume Bytes = 1G
Storage = "SVN_Full_Copy"
}
Storage {
Name = SVN_Full_Copy
Password =
Address = FileServer1
SDPort = 9103
Device = SVN_Full_Copy
Media Type = File
Maximum Concurrent Jobs = 20
}
bacula-sd.conf
Device {
Name = SVN_Full_Copy
Archive Device = /mnt/mac_backup/Bacula/SVN/Full
Media Type = File
LabelMedia = yes
Random Access = yes
AutomaticMount = yes
RemovableMedia = no
AlwaysOpen = no
}
I have updated the volume in bconsole. The DB shows:
mysql> SELECT * FROM Pool WHERE PoolId = 17;
++---+-+-+-++-+--+++-+-+---+-+---+--+---++-+---+---+++---+---+
| PoolId | Name | NumVols | MaxVols | UseOnce | UseCatalog |
AcceptAnyVolume | VolRetention | VolUseDuration | MaxVolJobs | MaxVolFiles |
MaxVolBytes | AutoPrune | Recycle | ActionOnPurge | PoolType | LabelType |
LabelFormat| Enabled | ScratchPoolId | RecyclePoolId | NextPoolId |
MigrationHighBytes | MigrationLowBytes | MigrationTime |
++---+-+-+-++-+--+++-+-+---+-+---+--+---++-+---+---+++---+---+
| 17 | SVN_Full_Copy | 4 | 0 | 0 | 1 |
0 | 604800 | 0 | 0 | 0 | 1073741824
| 1 | 1 | 0 | | 0 | SVN_Full_Copy_ |
1 | 0 | 0 | 0 | 0 |
0 | 0 |
++---+-+-+-++-+--+++-+-+---+-+---+--+---++-+---+---+++---+---+
1 row in set (0.00 sec)
If I can provide anymore info that may help you to help me, please let me know
as I need to resolve this issue :-(
Thank you in anticipation!
Joe Nyland
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when
[Bacula-users] RHEL 4/5/6 - Fedora 15/16 Bacula RPM repository
Hello,
I have updated the repository with the latest version, since the
soname of the catalogue library has now changed to
libbaccats-%{version}.so; it is advised that you check the links of
the alternatives system after the upgrade as the package bacula-libs
has been adapted.
I will update the bacula-docs package tomorrow.
http://repos.fedorapeople.org/repos/slaanesh/bacula/README.txt
Please read the README.Fedora file in bacula-common.
Regards,
--Simone
--
You cannot discover new oceans unless you have the courage to lose
sight of the shore (R. W. Emerson).
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Updating from debian package 5.0.2 to current version
W dniu 18.01.2012 08:30, Geert Stappers pisze: > Op 20120117 om 15:08 schreef Richard Marnau: >> Hi all, >> >> I'm wondering which steps I actually have to do to upgrade from the >> default debian repository bacula to the current version. >> I did download the current version and compiled (make / make install) konso>> the files. What are the next steps? >> Are there any database upgrades necessary? > > More questions: > > What does the Bacula Release notes say? > Which item in the Bacula Changelog triggered you to start an upgrade? > How went the upgrade of a Bacula client? > Where will you publish your success story? > Are you familiar with http://alioth.debian.org/projects/pkg-bacula ? On github [1] I published my attempts to port 5.2.3 into stable (squeeze) and old-stable (lenny). Old-stalbe port doesn't contain bat and try-icon-monitor as I had no time to play with QT dependency. QT library present in lenny is too old. Some basic build instruction you can find on WiKi. [1] https://github.com/naszaklasa/bacula -- Bartosz Cisek Admin email: bartosz.ci...@nasza-klasa.pl tel: +48 519 300 122 Nasza Klasa Sp. z o.o., ul. Gen. J. Bema 2, 50-265 Wrocław Sąd Rejonowy dla Wrocławia - Fabrycznej we Wrocławiu, VI Wydział Gospodarczy Krajowego Rejestru Sądowego, nr KRS:289629, NIP:898-21-22-104 REGON:020586020, Kapitał zakładowy: 67 850,00 PLN -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
