Re: [Bacula-users] Purge volume not freeing up disk space
On 2019-03-03 07:07, Shawn Rappaport wrote: I just purged a 100GB volume (my maximum volume size) and it shows as purged but didn't free up disk space. Maybe I misunderstood what the purge command is for since I expected the file size of daily-0 to drop to 0GB but it still shows as 100GB: | 1 | daily-0| Purged| 1 | 107,374,153,682 | 24 | 777,600 | 1 |0 | 0 | File1 | 1 | 0 | 2019-02-15 01:39:38 | 0 | | 36 How do I get it to delete the contents of the file so it is no longer 100GB in size? If I delete the file altogether, will it simply be re-created as needed? Thanks! --Shawn You need to use the truncate command to free up the disk space used by the volume. https://www.bacula.org/9.4.x-manuals/en/main/New_Features_in_7_0_0.html#SECTION00817000 ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Purge volume not freeing up disk space
When your storage is DISK. the volumen use "format" Bacula. If the file (volumen) example volumen0001,FULL to 5GB. Recicle, prune o purge... no free space. du -sch volumen0001 (always 5GB). is a normal. I do.if sda1 free total 100GB. then recommend i can create only 18 volumen (5GB each) for 90GB. so I avoid getting to the top- On Sat, Mar 2, 2019 at 2:10 PM Shawn Rappaport wrote: > I just purged a 100GB volume (my maximum volume size) and it shows as > purged but didn't free up disk space. Maybe I misunderstood what the purge > command is for since I expected the file size of daily-0 to drop to 0GB but > it still shows as 100GB: > | 1 | daily-0| Purged| 1 | 107,374,153,682 | 24 > | 777,600 | 1 |0 | 0 | File1 | 1 | > 0 | 2019-02-15 01:39:38 | 0 | > | 36 > > How do I get it to delete the contents of the file so it is no longer > 100GB in size? If I delete the file altogether, will it simply be > re-created as needed? > > Thanks! > > --Shawn > > > ___ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > -- # # Sistema Operativo: Debian # #Caracas, Venezuela # # ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] MySQL files filling up the disk
On 3/2/19 1:35 PM, Shawn Rappaport wrote: > I'm running Bacula 9.06 on CentOS 7.5 with MariaDB version 5.5.56-2. The > Bacula-web interface shows the DB is 69.10GB in size. However, the MySQL > files on my server are consuming 442GB of disk space, which is starting to > fill up the disk on my Director server. I see 374 mysql-bin files which are > almost all 1.1GB in size. I also see an ibdata1 file which is 73GB. > > Do I need to perform some sort of maintenance on the DB to get things under > control? Sorry for my ignorance but I'm not very familiar with MySQL. Those mysql-bin files are binary logs, MySQL's record of what changes it applied to the database when. MySQL automatically rotates the binary log and starts a new one every 1GB (by default). There's two issues here: 1. You should never have binary logging turned on without ALSO turning on automatic log expiration. The configuration command is expire_logs_days. Add it to your MySQL configuration file and set it to an integer number of days. You almost certainly don't need it set higher than three days. The configuration file won't take effect until you next restart MySQL; you can set it immediately by logging into MySQL as the superuser and executing this command: SET GLOBAL expire_logs_days = 1; (or however many days you decide you need) If you then issue this command as well: FLUSH LOGS; then MySQL will cleanly prune all of the old log files. Otherwise, it will prune them the next time it does a binary log rotation. 2. *Unless* you're replicating to another server or want to be able to do point-in-time recovery, you don't need binary logging enabled *anyway*. If you want to turn binary logging off: * stop MySQL; * edit the configuration file and remove or comment out the log_bin directive; * delete all of the mysql_bin* files; * restart MySQL. MariaDB 5.5.56 still defaults to /etc/my.cnf as the default MySQL configuration file. It's probably pretty minimal, and most of the statements in it probably either reiterate compiled-in defaults or are possibly actively harmful. Now, your ibdata1 file. That is the InnoDB global tablespace which contains all of your global data. If it's 73GB, it's because you're not using innodb_file_per_table and it contains ALL of your data. An InnoDB tablespace is like a filesystem. You can grow it easily, but there's no simple way to shrink it. If you want to switch to using innodb_file_per_table, which is recommended on all recent MySQL branches, you need to dump your data, re-initialize MySQL, and reload it. MariaDB or MySQL 5.5 is getting pretty long in the tooth. You might want to consider updating to a newer branch. -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958 ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] MySQL files filling up the disk
Am 02.03.2019 um 19:35 schrieb Shawn Rappaport: > I'm running Bacula 9.06 on CentOS 7.5 with MariaDB version 5.5.56-2. > The Bacula-web interface shows the DB is 69.10GB in size. However, the > MySQL files on my server are consuming 442GB of disk space, which is > starting to fill up the disk on my Director server. I see 374 mysql-bin > files which are almost all 1.1GB in size. Sounds like binary logfiles. Check, if binary logging is enabled in MariaDB. You can limit the total size of binary logfiles or you can turn it off altogether if you don't need it. https://mariadb.com/kb/en/library/binary-log/ > I also see an ibdata1 file which is 73GB. That's the actual database. > Do I need to perform some sort of maintenance on the DB to get things under > control? IMHO, a "OPTIMIZE TABLE" statement every now and then, especially for the Bacula tables "Filename" and "FileSet" shouldn't hurt but shouldn't be really required either. HTH, Sebastian ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] MySQL files filling up the disk
I'm running Bacula 9.06 on CentOS 7.5 with MariaDB version 5.5.56-2. The Bacula-web interface shows the DB is 69.10GB in size. However, the MySQL files on my server are consuming 442GB of disk space, which is starting to fill up the disk on my Director server. I see 374 mysql-bin files which are almost all 1.1GB in size. I also see an ibdata1 file which is 73GB. Do I need to perform some sort of maintenance on the DB to get things under control? Sorry for my ignorance but I'm not very familiar with MySQL. Thanks! --Shawn ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] Purge volume not freeing up disk space
I just purged a 100GB volume (my maximum volume size) and it shows as purged but didn't free up disk space. Maybe I misunderstood what the purge command is for since I expected the file size of daily-0 to drop to 0GB but it still shows as 100GB: | 1 | daily-0| Purged| 1 | 107,374,153,682 | 24 | 777,600 | 1 |0 | 0 | File1 | 1 |0 | 2019-02-15 01:39:38 | 0 | | 36 How do I get it to delete the contents of the file so it is no longer 100GB in size? If I delete the file altogether, will it simply be re-created as needed? Thanks! --Shawn ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Error running bacula-sd 9.2.2 on a Zyxel NSA310 [SOLVED]
Hello, From the code, it is *very* clear that the programmer (not me) knew that the code was not portable. He provided what appears to be correct #ifdefing to handle the case, including the appropriate modifications to configure.in to detect whether or not accept4() exists. The programmer handled this situation in the same way that Bacula has been handling similar situations for almost 20 years now ... Best regards, Kern On 3/1/19 7:11 PM, Dmitri Maziuk via Bacula-users wrote: > On 3/1/2019 10:10 AM, Josh Fisher wrote: >> >> On 3/1/2019 6:34 AM, Kern Sibbald wrote: > >>> At this point, my best assessment is that there is a bug in the Zyxel >>> libraries. >> >> >> It is certainly a bug in the Zyxel libraries. The accept4() is >> throwing a ENOSYS, meaning that the function is simply not >> implemented. It seems the header file being used (sys/socket.h) does >> not match the installed library. >> >> Nevertheless, accept4() is a convenience extension and it doesn't >> seem worth potentially breaking some platforms to save one or two >> fcntl() calls. > > My point was, what are the chances the programmer had no clue about > accept4() being non-portable non-POSIX gunk in the first place? One > wonders what flags are actually being passed to the call in question. > > (Yes, I've built GNU stuff on SPARC Solaris with Sun Studio. That's > where contempt for libtool and "gunk" pronunciation of "GNU C" comes > from.) > > Dima > > > ___ > 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
