I just noticed that though my freepbx backup module is up to date and installed; it’s not performing the backup… no new entries as far as the weekly backup, and the ‘Now’ setting doesn’t seem to work for an immediate backup either…
Tried my first backup today on PBX 2.3.1.1 & Backup 2.1.4.8. It created the Backup directory but no backup file. No matter how I set the schedule it will not backup.
not quite sure what may be going on. logrotate has nothing to do with the FreePBX backups - that would be something you or your distro may have setup. The recent trixbox security issue a couple weeks ago was fixed by their messing with cron, there is a chance they may have broken something as others reported their cron jobs removed and backup uses cron. However, if configured right these should be backups as user asterisk and not user root which I believe is what trixbox was using.
Well I’m running trixbox 2.2.x (9 and updated to current as of Last friday so should be 2.2.12). My backups have been running just fine each and every night. I run them at 4am.
227624 -rw-rw-r-- 1 asterisk asterisk 232851843 Jan 1 04:01 20080101.04.00.01.tar.gz
227580 -rw-rw-r-- 1 asterisk asterisk 232804782 Jan 2 04:01 20080102.04.00.01.tar.gz
226824 -rw-rw-r-- 1 asterisk asterisk 232031868 Jan 3 04:01 20080103.04.00.01.tar.gz
227676 -rw-rw-r-- 1 asterisk asterisk 232904251 Jan 4 04:01 20080104.04.00.01.tar.gz
223636 -rw-rw-r-- 1 asterisk asterisk 228771326 Jan 5 04:01 20080105.04.00.01.tar.gz
223636 -rw-rw-r-- 1 asterisk asterisk 228771677 Jan 6 04:01 20080106.04.00.02.tar.gz
223636 -rw-rw-r-- 1 asterisk asterisk 228771770 Jan 7 04:01 20080107.04.00.01.tar.gz
223404 -rw-r–r-- 1 asterisk asterisk 228533535 Jan 8 04:01 20080108.04.00.01.tar.gz
223256 -rw-r–r-- 1 asterisk asterisk 228380902 Jan 9 04:01 20080109.04.00.01.tar.gz
logrotate in trixbox is done via the /etc/logrotate.d/* files. so review that directory and see what files might have changes to them that would be causing the issue. Mine are running fine and I’ve even tweaked the asterisk file to include a few other files I see as important to me and those are still there and rotating.
Come on the thread is regards the Trixbox 2.3 Beta / now 2.4 ISO package not the Trixbox 2.2 base. Which I agree is fine.
I have three different boxes built from the 2.4 ISO no yum updates yet. After I did remove and reinstall of the Backup function from the FreePBX modules admin screen a "now" backup ran and everything was fine. Checked the results with tar -tvf [file].
Added back in the Daily and Weekly definitions and again last night no Backup files created. Based on the way the GUI panels act I am thinking that the various backup definitions are being written / rewritten over each other but since I am not real clear on rather this is in mySQL or just cron and script files I am only guessing.
Philippe, can you look at this please and maybe give me some direction on what to look at to get it resolved / assist you in debugging it if it is broken..
TIA....
PS: Logroate is repaired and working, there is a problem in the 2.4 ISO and the bug report on the Trixbox site has the details and resolution. They will fix it in the next ISO but all you have to do is remove a duplicate file entry in the logrotate.d directory.
backup has no concept of year and does nothing more than schedule cron jobs for the backups. The code has not been changed in a very long time, nor other code in FreePBX that messes with cron. Other people’s backups and my backup’s have run fine through 2008. As others have mentioned, this sounds like an isolated or distro related bug.
phonebuff - to answer your direct request to me, no I won’t look at it. I don’t have the time nor is there enough evidence to indicate that this is something effecting all FreePBX systems to justify the time. The code is open source so by all means you or many others can review it and report back if there are issues. The other alternative would be to engage in one of the many paid support options (ours or other available) to review your system and see what is going on.
make sure you remove it completely - delete it from the directory so that it re-installs it form the server. As far as distro issues, the fact that it is dependent on cron as well as proper user permissions on apache makes it a very easy target for a distro problem if there is something messing with cron. MySQL has a table that is effectively the cron settings, and there is often a file in /etc/asterisk called backup.conf that gets left over without being deleted, that can give you an idea of what the crontab entry should look like. Also - make sure that your asterisk email account is being delivered somewhere. If there is an issue going on when cron tries to run, you want to get the email from cron which is going to be sent to the user that scheduled the cron job, asterisk.
lastly - to check if the entry is even there, you can type crontab -l -u asterisk (as root) and see if it is even scheduled.
I did find something earlier today with /etc/asterisk/backup.conf Even though a number of updates had been done since to the backup schedules it still had a Jan 1 modified date, which is when I installed from ISO, make a “NOW” Backup called SaveCFG and then restored the backup made under the same name on a 2.3.10 ISO build.
I deleted the Module again through the GUI, but the conf file was still there. So I move it to. backup.bak and then installed the module and set it up, new backup.conf with proper CRON format and settings appeared as did the ampbackup.pl in the proper directory.
Will let you know in the morning rather I get a good backup.
not quite - the last argument to ampbackup.pl is an index into the backup table that tells it what to do - so you can’t just arbitrarily put in an entry without having a matching table entry that has the particular backup configuration info.
techworks,
at some point many moons ago, trixbox broke how they installed backup by trying to second guess the system. I sure hope that is long in the past. The file is not in /var/lib/asterisk/bin by design. It is in the bin directory under the module and gets linked to /var/lib/asterisk/bin automatically upon install and the first time you press reload. Copying the file is a bad thing to do because it will cause the auto-linking process to fail (by design, in case you really did modify your own version). So when a new module comes along with a change, bug fix, or other to that file, you don’t get it because you broke the link.