Greetings! A well-researched and well-written posting! Comments inline.
________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Warnke Sent: Monday, April 24, 2006 9:30 AM To: bacula-users@lists.sourceforge.net Subject: [Bacula-users] Constructive criticism of current bacula systems ==snip=== No comments on RPM or SQLite. Config files are on par with other systems... There _are_ a lot of resource types, and it does take a while to sort them all out... 4) The way that incremental and differentials are structured does not allow for good differential pooling since incremental can be based on differentials. Because of this you can't recycle your differentials before you re-run a full backup. If incremental were only based on fulls or incremental, you can recycle your differentials on a faster cycle to reduce tape space for in exchange for longer restore times for older files. -> That is an interesting point. Any subsequent differentials obsoletes previous when aiming for recovering to most current state. The problem I see, is that recycling a differential will orphan all the incrementals referring to them(between diff and new diff or full), making them useless. I can't seem to understand your second point if incrementals were only based on full or inc... If you wanted to that, you could simply remove the diffs from the schedule, and never run one? I can't seem to see the useability of a lone differential that can't be used for baseline for subsequent incrementals. I've been known to misunderstand, so bear with me.. 5) Does not back up all files. As noted in the documentation, bacula uses mtime for incremental leading to possibility of missing files in an incremental and differential backup because of movement, incorrect touch, system date set incorrectly, or possibly other issue. This alone would be a show stopper if the rest of the system was not as refined as it is. This is noted in the docs, but I did not discover it until after we started evaluating it. -> I'd have to agree on this one. I'm not sure how much of a risk it would be in a real environment, though. Basics like system times and dates should(!) always be taken care of by NTP or similar. Implementing a different way of tagging files for incrementals, (querying the master catalog) for comparing name, inode#, times, etc will be hard on the catalog and director. 6) Does not track deletions between full backups. Restoration will uncover deleted files. Over a long period of time this could lead to restorations that exceed the space on the partition that is being restored especially for sites that have long retention periods and heavy tunover. The major problem is that there is probably no way to stort out those files that belong and those that do not! -> Again, agreed. We're using Veritas NetBackup, and have the ability to use "True Image Restore" which will keep track of this, at the expense of increased catalog size and traffic. It is #3 priority on the project page, so keep your hope up. In the meantime, it may be possible to do some clever scripting outside of Bacula to produce a change log per directory structure that could be used during the cleanup phase... but that is beside the point. =This list does not mean that we will not end up using bacula since this list looks better than the alternatives, but is a list of items that give me pause to implement this system on a full time production status. At a minimum these items should be noted in the documentation ( some already are ). This list is also out there for others who might be evaluating this project for their use as well. -> The list of features _does_ look a lot better than any OSS alternative. A lot better than many of the commercial offerings also, by the way. (Choice of database backend, for example: Brilliant. The manual is another stellar feature.) The list of shortcomings (in my opinion) is also shorter than competitors. Native client for Windows; a good thing. The list of features in development, and on the agenda is impressive. TrueImageRestore, as mentioned, Syntethic fulls and base jobs will be something most commercial systems can only wish for. Migrating data from disk to tape pools is something I'm looking forward to also. >Cheers, >Eric Warnke >Systems Administrator >Research IT, SUNY Albany Knut Meidal ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
