4 \chapter{Catalog Maintenance}
5 \label{CatMaintenanceChapter}
6 \index[general]{Maintenance!Catalog }
7 \index[general]{Catalog Maintenance }
9 Without proper setup and maintenance, your Catalog may continue to grow
10 indefinitely as you run Jobs and backup Files, and/or it may become
11 very inefficient and slow. How fast the size of your
12 Catalog grows depends on the number of Jobs you run and how many files they
13 backup. By deleting records within the database, you can make space available
14 for the new records that will be added during the next Job. By constantly
15 deleting old expired records (dates older than the Retention period), your
16 database size will remain constant.
18 If you started with the default configuration files, they already contain
19 reasonable defaults for a small number of machines (less than 5), so if you
20 fall into that case, catalog maintenance will not be urgent if you have a few
21 hundred megabytes of disk space free. Whatever the case may be, some knowledge
22 of retention periods will be useful.
25 \section{Setting Retention Periods}
26 \index[general]{Setting Retention Periods }
27 \index[general]{Periods!Setting Retention }
29 {\bf Bacula} uses three Retention periods: the {\bf File Retention} period,
30 the {\bf Job Retention} period, and the {\bf Volume Retention} period. Of
31 these three, the File Retention period is by far the most important in
32 determining how large your database will become.
34 The {\bf File Retention} and the {\bf Job Retention} are specified in each
35 Client resource as is shown below. The {\bf Volume Retention} period is
36 specified in the Pool resource, and the details are given in the next chapter
41 \item [File Retention = \lt{}time-period-specification\gt{}]
42 \index[general]{File Retention }
43 The File Retention record defines the length of time that Bacula will keep
44 File records in the Catalog database. When this time period expires, and if
45 {\bf AutoPrune} is set to {\bf yes}, Bacula will prune (remove) File records
46 that are older than the specified File Retention period. The pruning will
47 occur at the end of a backup Job for the given Client. Note that the Client
48 database record contains a copy of the File and Job retention periods, but
49 Bacula uses the current values found in the Director's Client resource to do
52 Since File records in the database account for probably 80 percent of the
53 size of the database, you should carefully determine exactly what File
54 Retention period you need. Once the File records have been removed from
55 the database, you will no longer be able to restore individual files
56 in a Job. However, with Bacula version 1.37 and later, as long as the
57 Job record still exists, you will be able to restore all files in the
60 Retention periods are specified in seconds, but as a convenience, there are
61 a number of modifiers that permit easy specification in terms of minutes,
62 hours, days, weeks, months, quarters, or years on the record. See the
63 \ilink{ Configuration chapter}{Time} of this manual for additional details
64 of modifier specification.
66 The default File retention period is 60 days.
68 \item [Job Retention = \lt{}time-period-specification\gt{}]
69 \index[general]{Job Retention }
70 The Job Retention record defines the length of time that {\bf Bacula}
71 will keep Job records in the Catalog database. When this time period
72 expires, and if {\bf AutoPrune} is set to {\bf yes} Bacula will prune
73 (remove) Job records that are older than the specified Job Retention
74 period. Note, if a Job record is selected for pruning, all associated File
75 and JobMedia records will also be pruned regardless of the File Retention
76 period set. As a consequence, you normally will set the File retention
77 period to be less than the Job retention period.
79 As mentioned above, once the File records are removed from the database,
80 you will no longer be able to restore individual files from the Job.
81 However, as long as the Job record remains in the database, you will be
82 able to restore all the files backuped for the Job (on version 1.37 and
83 later). As a consequence, it is generally a good idea to retain the Job
84 records much longer than the File records.
86 The retention period is specified in seconds, but as a convenience, there
87 are a number of modifiers that permit easy specification in terms of
88 minutes, hours, days, weeks, months, quarters, or years. See the \ilink{Configuration chapter}{Time} of this manual for additional details of
89 modifier specification.
91 The default Job Retention period is 180 days.
93 \item [AutoPrune = \lt{}yes/no\gt{}]
94 \index[general]{AutoPrune }
95 If AutoPrune is set to {\bf yes} (default), Bacula will automatically apply
96 the File retention period and the Job retention period for the Client at the
99 If you turn this off by setting it to {\bf no}, your Catalog will grow each
103 \label{CompactingMySQL}
104 \section{Compacting Your MySQL Database}
105 \index[general]{Database!Compacting Your MySQL }
106 \index[general]{Compacting Your MySQL Database }
108 Over time, as noted above, your database will tend to grow. I've noticed that
109 even though Bacula regularly prunes files, {\bf MySQL} does not effectively
110 use the space, and instead continues growing. To avoid this, from time to
111 time, you must compact your database. Normally, large commercial database such
112 as Oracle have commands that will compact a database to reclaim wasted file
113 space. MySQL has the {\bf OPTIMIZE TABLE} command that you can use, and SQLite
114 version 2.8.4 and greater has the {\bf VACUUM} command. We leave it to you to
115 explore the utility of the {\bf OPTIMIZE TABLE} command in MySQL.
117 All database programs have some means of writing the database out in ASCII
118 format and then reloading it. Doing so will re-create the database from
119 scratch producing a compacted result, so below, we show you how you can do
120 this for MySQL, PostgreSQL and SQLite.
122 For a {\bf MySQL} database, you could write the Bacula database as an ASCII
123 file (bacula.sql) then reload it by doing the following:
127 mysqldump -f --opt bacula > bacula.sql
128 mysql bacula < bacula.sql
133 Depending on the size of your database, this will take more or less time and a
134 fair amount of disk space. For example, if I cd to the location of the MySQL
135 Bacula database (typically /opt/mysql/var or something similar) and enter:
143 I get {\bf 620,644} which means there are that many blocks containing 1024
144 bytes each or approximately 635 MB of data. After doing the {\bf mysqldump}, I
145 had a bacula.sql file that had {\bf 174,356} blocks, and after doing the {\bf
146 mysql} command to recreate the database, I ended up with a total of {\bf
147 210,464} blocks rather than the original {\bf 629,644}. In other words, the
148 compressed version of the database took approximately one third of the space
149 of the database that had been in use for about a year.
151 As a consequence, I suggest you monitor the size of your database and from
152 time to time (once every six months or year), compress it.
154 \label{DatabaseRepair}
155 \label{RepairingMySQL}
156 \section{Repairing Your MySQL Database}
157 \index[general]{Database!Repairing Your MySQL }
158 \index[general]{Repairing Your MySQL Database }
160 If you find that you are getting errors writing to your MySQL database, or
161 Bacula hangs each time it tries to access the database, you should consider
162 running MySQL's database check and repair routines. The program you need to
163 run depends on the type of database indexing you are using. If you are using
164 the default, you will probably want to use {\bf myisamchk}. For more details
165 on how to do this, please consult the MySQL document at:
166 \elink{http://www.mysql.com/doc/en/Repair.html}{http://www.mysql.com/doc/en/Repair.html}.
168 If the errors you are getting are simply SQL warnings, then you might try
169 running dbcheck before (or possibly after) using the MySQL database repair
170 program. It can clean up many of the orphaned record problems, and certain
171 other inconsistencies in the Bacula database.
173 A typical cause of MySQL database problems is if your partition fills. In
174 such a case, you will need to create additional space on the partition or
175 free up some space then repair the database probably using {\bf myisamchk}.
176 Recently my root partition filled and the MySQL database was corrupted.
177 Simply running {\bf myisamchk -r} did not fix the problem. However,
178 the following script did the trick for me:
185 t=`echo $i | cut -f 1 -d '.' -`
186 mysql bacula <<END_OF_DATA
192 chown mysql:mysql ${i}
198 I invoked it with the following commands:
202 cd /var/lib/mysql/bacula
207 Then after ensuring that the database was correctly fixed, I did:
210 cd /var/lib/mysql/bacula
215 \section{MySQL Table is Full}
216 \index[general]{Database!MySQL Table is Full}
217 \index[general]{MySQL Table is Full}
219 If you are running into the error {\bf The table 'File' is full ...},
220 it is probably because on version 4.x MySQL, the table is limited by
221 default to a maximum size of 4 GB and you have probably run into
222 the limit. The solution can be found at:
223 \elink{http://dev.mysql.com/doc/refman/5.0/en/full-table.html}{http://dev.mysql.com/doc/refman/5.0/en/full-table.html}
225 You can display the maximum length of your table with:
230 SHOW TABLE STATUS FROM bacula like "File";
234 If the column labeled "Max\_data\_length" is around 4Gb, this is likely
235 to be the source of your problem, and you can modify it with:
240 ALTER TABLE File MAX_ROWS=281474976710656;
244 Alternatively you can modify your /etc/my.conf file before creating the
245 Bacula tables, and in the [mysqld] section set:
249 set-variable = myisam_data_pointer_size=6
253 The above myisam data pointer size must be made before you create your
254 Bacula tables or it will have no effect.
256 The row and pointer size changes should already be the default on MySQL
257 version 5.x, so making these changes should only be necessary on MySQL 4.x
258 depending on the size of your catalog database.
260 \section{MySQL Server Has Gone Away}
261 \index[general]{Database!MySQL Server Has Gone Away}
262 \index[general]{MySQL Server Has Gone Away}
263 If you are having problems with the MySQL server disconnecting or with
264 messages saying that your MySQL server has gone away, then please read
265 the MySQL documentation, which can be found at:
267 \elink{http://dev.mysql.com/doc/refman/5.0/en/gone-away.html}{http://dev.mysql.com/doc/refman/5.0/en/gone-away.html}
269 \section{MySQL Temporary Tables}
270 When doing backups with large numbers of files, MySQL creates some
271 temporary tables. When these tables are small they can be held in
272 system memory, but as they approach some size, they
273 spool off to disk. The default location for these temp tables is
274 /tmp. Once that space fills up, Bacula daemons such as the Storage
275 daemon doing spooling can get strange errors. E.g.
279 Fatal error: spool.c:402 Spool data read error.
280 Fatal error: backup.c:892 Network send error to SD. ERR=Connection reset by
285 What you need to do is setup MySQL to use a different (larger) temp
286 directory, which can be set in the /etc/my.cnf with these variables
291 tmpdir=/path/to/larger/tmpdir
292 bdb_tmpdir=/path/to/larger/tmpdir
296 \label{RepairingPSQL}
297 \section{Repairing Your PostgreSQL Database}
298 \index[general]{Database!Repairing Your PostgreSQL }
299 \index[general]{Repairing Your PostgreSQL Database }
301 The same considerations apply that are indicated above for MySQL. That is,
302 consult the PostgreSQL documents for how to repair the database, and also
303 consider using Bacula's dbcheck program if the conditions are reasonable for
306 \label{DatabasePerformance}
307 \section{Database Performance Issues}
308 \index[general]{Database Performance Issues}
309 \index[general]{Performance!Database}
311 There are a considerable number of ways each of the databases can be
312 tuned to improve the performance. Going from an untuned database to one
313 that is properly tuned can make a difference of a factor of 100 or more
314 in the time to insert or search for records.
316 For each of the databases, you may get significant improvements by adding
317 additional indexes. The comments in the Bacula make\_xxx\_tables give some
318 indications as to what indexes may be appropriate. Please see below
319 for specific instructions on checking indexes.
321 For MySQL, what is very important is to use the examine the
322 my.cnf file (usually in /etc/my.cnf).
323 You may obtain significant performances by switching to
324 the my-large.cnf or my-huge.cnf files that come with the MySQL source
327 For SQLite3, one significant factor in improving the performance is
328 to ensure that there is a "PRAGMA synchronous = NORMAL;" statement.
329 This reduces the number of times that the database flushes the in memory
330 cache to disk. There are other settings for this PRAGMA that can
331 give even further performance improvements at the risk of a database
332 corruption if your system crashes.
334 For PostgreSQL, you might want to consider turning fsync off. Of course
335 doing so can cause corrupted databases in the event of a machine crash.
336 There are many different ways that you can tune PostgreSQL, the
337 following document discusses a few of them:
338 \elink{http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html}{http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html}.
340 There is also a PostgreSQL FAQ question number 3.3 that may
341 answer some of your questions about how to improve performance
342 of the PostgreSQL engine:
343 \elink{http://www.postgresql.org/docs/faqs.FAQ.html\#3.3}{http://www.postgresql.org/docs/faqs.FAQ.html\#3.3}.
344 % TODO: verify above is correct. is this okay for book?
346 Also for PostgreSQL, look at what "effective\_cache\_size". For a 2GB memory
347 machine, you probably want to set it at 131072, but don't set it too high.
348 In addition, for a 2GB system, work\_mem = 256000 and
349 maintenance\_work\_mem = 256000 seem to be reasonable values. Make
350 sure your checkpoint\_segments is set to at least 8.
354 \section{Performance Issues Indexes}
355 \index[general]{Database Performance Issues Indexes}
356 \index[general]{Performance!Database}
357 One of the most important considerations for improving performance on
358 the Bacula database is to ensure that it has all the appropriate indexes.
359 Several users have reported finding that their database did not have
360 all the indexes in the default configuration. In addition, you may
361 find that because of your own usage patterns, you need additional indexes.
363 The most important indexes for performance are the two indexes on the
364 {\bf File} table. The first index is on {\bf FileId} and is automatically
365 made because it is the unique key used to access the table. The other
366 one is the (JobId, PathId, Filename) index. If these Indexes
367 are not present, your performance may suffer a lot.
369 \subsection{PostgreSQL Indexes}
370 On PostgreSQL, you can check to see if you have the proper indexes using
371 the following commands:
376 select * from pg_indexes where tablename='file';
380 If you do not see output that indicates that all three indexes
381 are created, you can create the two additional indexes using:
386 CREATE INDEX file_jobid_idx on file (jobid);
387 CREATE INDEX file_jpf_idx on file (jobid, pathid, filenameid);
391 Make sure that you doesn't have an index on File (filenameid, pathid).
393 \subsection{MySQL Indexes}
394 On MySQL, you can check if you have the proper indexes by:
399 show index from File;
403 If the indexes are not present, especially the JobId index, you can
404 create them with the following commands:
409 CREATE INDEX file_jobid_idx on File (JobId);
410 CREATE INDEX file_jpf_idx on File (JobId, PathId, FilenameId);
414 Though normally not a problem, you should ensure that the indexes
415 defined for Filename and Path are both set to 255 characters. Some users
416 reported performance problems when their indexes were set to 50 characters.
422 show index from Filename;
423 show index from Path;
427 and what is important is that for Filename, you have an index with
428 Key\_name "Name" and Sub\_part "255". For Path, you should have a Key\_name
429 "Path" and Sub\_part "255". If one or the other does not exist or the
430 Sub\_part is less that 255, you can drop and recreate the appropriate
436 DROP INDEX Path on Path;
437 CREATE INDEX Path on Path (Path(255));
439 DROP INDEX Name on Filename;
440 CREATE INDEX Name on Filename (Name(255));
445 \subsection{SQLite Indexes}
446 On SQLite, you can check if you have the proper indexes by:
450 sqlite <path>/bacula.db
451 select * from sqlite_master where type='index' and tbl_name='File';
455 If the indexes are not present, especially the JobId index, you can
456 create them with the following commands:
460 sqlite <path>/bacula.db
461 CREATE INDEX file_jobid_idx on File (JobId);
462 CREATE INDEX file_jfp_idx on File (JobId, PathId, FilenameId);
468 \label{CompactingPostgres}
469 \section{Compacting Your PostgreSQL Database}
470 \index[general]{Database!Compacting Your PostgreSQL }
471 \index[general]{Compacting Your PostgreSQL Database }
473 Over time, as noted above, your database will tend to grow. I've noticed that
474 even though Bacula regularly prunes files, PostgreSQL has a {\bf VACUUM}
475 command that will compact your database for you. Alternatively you may want to
476 use the {\bf vacuumdb} command, which can be run from a cron job.
478 All database programs have some means of writing the database out in ASCII
479 format and then reloading it. Doing so will re-create the database from
480 scratch producing a compacted result, so below, we show you how you can do
483 For a {\bf PostgreSQL} database, you could write the Bacula database as an
484 ASCII file (bacula.sql) then reload it by doing the following:
488 pg_dump -c bacula > bacula.sql
489 cat bacula.sql | psql bacula
494 Depending on the size of your database, this will take more or less time and a
495 fair amount of disk space. For example, you can {\bf cd} to the location of
496 the Bacula database (typically /usr/local/pgsql/data or possible
497 /var/lib/pgsql/data) and check the size.
499 There are certain PostgreSQL users who do not recommend the above
500 procedure. They have the following to say:
502 need to be dumped/restored to keep the database efficient. A normal
503 process of vacuuming will prevent the database from every getting too
504 large. If you want to fine-tweak the database storage, commands such
505 as VACUUM FULL, REINDEX, and CLUSTER exist specifically to keep you
506 from having to do a dump/restore.
508 Finally, you might want to look at the PostgreSQL documentation on
510 \elink{http://www.postgresql.org/docs/8.1/interactive/maintenance.html}{http://www.postgresql.org/docs/8.1/interactive/maintenance.html}.
512 \section{Compacting Your SQLite Database}
513 \index[general]{Compacting Your SQLite Database }
514 \index[general]{Database!Compacting Your SQLite }
516 First please read the previous section that explains why it is necessary to
517 compress a database. SQLite version 2.8.4 and greater have the {\bf Vacuum}
518 command for compacting the database.
522 cd {\bf working-directory}
523 echo 'vacuum;' | sqlite bacula.db
527 As an alternative, you can use the following commands, adapted to your system:
532 cd {\bf working-directory}
533 echo '.dump' | sqlite bacula.db > bacula.sql
535 sqlite bacula.db < bacula.sql
540 Where {\bf working-directory} is the directory that you specified in the
541 Director's configuration file. Note, in the case of SQLite, it is necessary to
542 completely delete (rm) the old database before creating a new compressed
545 \section{Migrating from SQLite to MySQL or PostgreSQL}
546 \index[general]{MySQL!Migrating from SQLite to }
547 \index[general]{Migrating from SQLite to MySQL or PostgreSQL}
549 You may begin using Bacula with SQLite then later find that you want to switch
550 to MySQL or Postgres for any of a number of reasons: SQLite tends to use more
551 disk than MySQL; when the database is corrupted it is often more catastrophic
552 than with MySQL or PostgreSQL. Several users have succeeded in converting by
553 exporting the SQLite data and then processing it with Perl scripts prior to
554 putting it into MySQL or PostgreSQL. This is, however, not a simple process.
555 Scripts are available on bacula source distribution under
556 \texttt{examples/database}.
558 \label{BackingUpBacula}
559 \section{Backing Up Your Bacula Database}
560 \index[general]{Backing Up Your Bacula Database }
561 \index[general]{Database!Backing Up Your Bacula }
563 If ever the machine on which your Bacula database crashes, and you need to
564 restore from backup tapes, one of your first priorities will probably be to
565 recover the database. Although Bacula will happily backup your catalog
566 database if it is specified in the FileSet, this is not a very good way to do
567 it, because the database will be saved while Bacula is modifying it. Thus the
568 database may be in an instable state. Worse yet, you will backup the database
569 before all the Bacula updates have been applied.
571 To resolve these problems, you need to backup the database after all the backup
572 jobs have been run. In addition, you will want to make a copy while Bacula is
573 not modifying it. To do so, you can use two scripts provided in the release
574 {\bf make\_catalog\_backup} and {\bf delete\_catalog\_backup}. These files
575 will be automatically generated along with all the other Bacula scripts. The
576 first script will make an ASCII copy of your Bacula database into {\bf
577 bacula.sql} in the working directory you specified in your configuration, and
578 the second will delete the {\bf bacula.sql} file.
580 The basic sequence of events to make this work correctly is as follows:
583 \item Run all your nightly backups
584 \item After running your nightly backups, run a Catalog backup Job
585 \item The Catalog backup job must be scheduled after your last nightly backup
587 \item You use {\bf RunBeforeJob} to create the ASCII backup file and {\bf
588 RunAfterJob} to clean up
591 Assuming that you start all your nightly backup jobs at 1:05 am (and that they
592 run one after another), you can do the catalog backup with the following
593 additional Director configuration statements:
597 # Backup the catalog database (after the nightly save)
599 Name = "BackupCatalog"
603 Schedule = "WeeklyCycleAfterBackup"
607 # WARNING!!! Passing the password via the command line is insecure.
608 # see comments in make_catalog_backup for details.
609 RunBeforeJob = "/home/kern/bacula/bin/make_catalog_backup"
610 RunAfterJob = "/home/kern/bacula/bin/delete_catalog_backup"
611 Write Bootstrap = "/home/kern/bacula/working/BackupCatalog.bsr"
613 # This schedule does the catalog. It starts after the WeeklyCycle
615 Name = "WeeklyCycleAfterBackup
616 Run = Level=Full sun-sat at 1:10
618 # This is the backup of the catalog
625 File = \lt{}working_directory\gt{}/bacula.sql
631 Be sure to write a bootstrap file as in the above example. However, it is preferable
632 to write or copy the bootstrap file to another computer. It will allow
633 you to quickly recover the database backup should that be necessary. If
634 you do not have a bootstrap file, it is still possible to recover your
635 database backup, but it will be more work and take longer.
638 \label{BackingUpBaculaSecurityConsiderations}
639 \section{Security considerations}
640 \index[general]{Backing Up Your Bacula Database - Security Considerations }
641 \index[general]{Database!Backing Up Your Bacula Database - Security Considerations }
643 We provide make\_catalog\_backup as an example of what can be used to backup
644 your Bacula database. We expect you to take security precautions relevant
645 to your situation. make\_catalog\_backup is designed to take a password on
646 the command line. This is fine on machines with only trusted users. It is
647 not acceptable on machines without trusted users. Most database systems
648 provide a alternative method, which does not place the password on the
651 The make\_catalog\_backup script contains some warnings about how to use it. Please
654 To help you get started, we know PostgreSQL has a password file,
655 \elink{.pgpass}{http://www.postgresql.org/docs/8.2/static/libpq-pgpass.html}, and
657 \elink{.my.cnf}{http://dev.mysql.com/doc/refman/4.1/en/password-security.html}.
659 Only you can decide what is appropriate for your situation. We have provided
660 you with a starting point. We hope it helps.
663 \label{BackingUPOtherDBs}
664 \section{Backing Up Third Party Databases}
665 \index[general]{Backing Up Third Party Databases }
666 \index[general]{Databases!Backing Up Third Party }
668 If you are running a database in production mode on your machine, Bacula will
669 happily backup the files, but if the database is in use while Bacula is
670 reading it, you may back it up in an unstable state.
672 The best solution is to shutdown your database before backing it up, or use
673 some tool specific to your database to make a valid live copy perhaps by
674 dumping the database in ASCII format. I am not a database expert, so I cannot
675 provide you advice on how to do this, but if you are unsure about how to
676 backup your database, you might try visiting the Backup Central site, which
677 has been renamed Storage Mountain (www.backupcentral.com). In particular,
679 \elink{Free Backup and RecoverySoftware}{http://www.backupcentral.com/toc-free-backup-software.html} page has
680 links to scripts that show you how to shutdown and backup most major
684 \section{Database Size}
685 \index[general]{Size!Database }
686 \index[general]{Database Size }
688 As mentioned above, if you do not do automatic pruning, your Catalog will grow
689 each time you run a Job. Normally, you should decide how long you want File
690 records to be maintained in the Catalog and set the {\bf File Retention}
691 period to that time. Then you can either wait and see how big your Catalog
692 gets or make a calculation assuming approximately 154 bytes for each File
693 saved and knowing the number of Files that are saved during each backup and
694 the number of Clients you backup.
696 For example, suppose you do a backup of two systems, each with 100,000 files.
697 Suppose further that you do a Full backup weekly and an Incremental every day,
698 and that the Incremental backup typically saves 4,000 files. The size of your
699 database after a month can roughly be calculated as:
703 Size = 154 * No. Systems * (100,000 * 4 + 10,000 * 26)
707 where we have assumed four weeks in a month and 26 incremental backups per month.
708 This would give the following:
712 Size = 154 * 2 * (100,000 * 4 + 10,000 * 26)
714 Size = 308 * (400,000 + 260,000)
716 Size = 203,280,000 bytes
720 So for the above two systems, we should expect to have a database size of
721 approximately 200 Megabytes. Of course, this will vary according to how many
722 files are actually backed up.
724 Below are some statistics for a MySQL database containing Job records for five
725 Clients beginning September 2001 through May 2002 (8.5 months) and File
726 records for the last 80 days. (Older File records have been pruned). For these
727 systems, only the user files and system files that change are backed up. The
728 core part of the system is assumed to be easily reloaded from the Red Hat rpms.
731 In the list below, the files (corresponding to Bacula Tables) with the
732 extension .MYD contain the data records whereas files with the extension .MYI
735 You will note that the File records (containing the file attributes) make up
736 the large bulk of the number of records as well as the space used (459 Mega
737 Bytes including the indexes). As a consequence, the most important Retention
738 period will be the {\bf File Retention} period. A quick calculation shows that
739 for each File that is saved, the database grows by approximately 150 bytes.
745 ============ ========= ===========
748 344,394,684 3,080,191 File.MYD
750 2,590,316 106,902 Filename.MYD
751 3,026,944 Filename.MYI
754 49,062 1,326 JobMedia.MYD
756 141,752 1,378 Job.MYD
760 1,299,512 22,233 Path.MYD
769 This database has a total size of approximately 450 Megabytes.
771 If we were using SQLite, the determination of the total database size would be
772 much easier since it is a single file, but we would have less insight to the
773 size of the individual tables as we have in this case.
775 Note, SQLite databases may be as much as 50\% larger than MySQL databases due
776 to the fact that all data is stored as ASCII strings. That is even binary
777 integers are stored as ASCII strings, and this seems to increase the space