Topic: Affa schedules not working

[Jáder]

I have two install of Affa for SME (following Wiki page) and have seen schedule of weekly and monthly retention not working as they should.

On one install I have no weekly after Nov 14 and no monthly after May!!
On another install I have almost same status.

So I have some doubts:
1) this is a known error/bug on Affa for SME
2) this is an error on my config
3) should I upgrade for new version (non-SME) from http://affa.sourceforge.net/

Any other tips/options ?

Regards


Jáder

[Stefano]

what about looking in the logs of your server and file a bug?

[idp_qbn]

Jader,
Do you read the emails from AFFA? They tell you what went wrong......or at least what AFFA thinks went wrong.

The most common problem I have found (in the hew times I have seen a problem) is that the keys between AFFA and the server to be backed up do not match. And the AFFA wiki/AFFA email told me that - and how to fix it.
ie remove keys on the server and regenerate new keys on the AFFA box and send them to the server.

As stefano says, look at the logs - and add the AFFA emails to that.

The newer version of AFFA is not SME specific. It can't be used to "rise" the backup server to be the data server, which is my favourite aspect of the older AFFA (which does work on SME8).

Cheers
Ian

[Jáder]

I'm sorry to say but the e-mail from Affa go directly to clients (owner of server I provide backup from my SME8 server running Affa for SME).
If a backup fails, they always send me a message (the e-mail from affa).
So I can verify the problem and restart job.

I'm not sure if all missing schedules (weeks and months only) were failed... and not sure how to verify that on my own server.

I'm seeking for tips why a weekly and monthly backup would fail and not those daily.

BTW There are diferent backup jobs for weekly and monthly or a Day31 backup is a monthly backup (a new label only) and stored twice (as day 31 and as month 12) ?

[janet]

jader

I'm not sure if all missing schedules (weeks and months only) were failed... and not sure how to verify that on my own server.
I'm seeking for tips why a weekly and monthly backup would fail and not those daily.

As you have been told, you need to provide the error message from the email report, & perhaps also look in the log files on the clients server.
There are many places to look/blame, & having that information will narrow down the possibilities, & highly likely will exactly pinpoint the problem.

Best thing I can suggest you do, is create a group on the server & direct the affa backup emails to that group address, which then distributes the mail to the original recipient & yourself (add yourself as a user first), that way you get a copy of all backup emails.
Then you can troubleshoot more effectively over the coming days, weeks, months.

BTW There are diferent backup jobs for weekly and monthly or a Day31 backup is a monthly backup (a new label only) and stored twice (as day 31 and as month 12) ?

I think that is a question, rather than a statement.
The same backup job does (or is capable of doing) daily, weekly, monthly & yearly backup job scheduling.

My guess is you may have random or erratic communications loss of some sort during the backup, & that's a wild guess.

[Jáder]

It got even MORE ODD:

[root@leopardo affa]# grep monthly *.log.1
affa.log.1:Sun Dec  1 20:00:05[START.7899]: Affa 1.0.0-3: Running /sbin/e-smith/affa --run Betty monthly
Betty.log.1:Sun Dec  1 20:00:06[7899]: Affa 1.0.0-3: Starting job Betty monthly (esc.xx.adv.br)
Betty.log.1:Sun Dec  1 20:00:12[7899]: Completed job Betty monthly (esc.xx.adv.br)

and this is list of archives for this job:

[root@leopardo affa]# affa --list-archives Betty
Affa version 1.0.0-3 on leop.jj.com.br (192.168.13.1)
+------------------------------------------------------------------------------+
| Job: Betty                                                                   |
| Description: xxxxx                                   |
| Directory: /var/affa/Betty/                                                  |
| Hostname: esc.xx.adv.br                                       |
| Email: jader@xx.adv.br                                               |
+-----------------------+----------------+--------------+--------+-------------+
| Date                  | Archive        |        Files |   Size |  Disk usage |
+-----------------------+----------------+--------------+--------+-------------+
| Tue 2013 Feb 26 21:50 | monthly.7      |         1889 |  105MB |   518GB/60% |
| Wed 2013 Mar 27 21:50 | monthly.6      |         1942 |  107MB |   524GB/61% |
| Wed 2013 Apr 17 21:50 | monthly.5      |         1877 |  102MB |   540GB/63% |
| Wed 2013 May 22 21:01 | monthly.4      |        11172 |  318MB |   568GB/66% |
| Sun 2013 Jun 09 21:07 | monthly.3      |        11217 |  319MB |   585GB/68% |
| Thu 2013 Jul 25 21:00 | monthly.2      |        11394 |  332MB |   637GB/74% |
| Wed 2013 Aug 28 21:00 | monthly.1      |        11576 |  347MB |   719GB/84% |
| Thu 2013 Sep 19 21:00 | monthly.0      |        11628 |  354MB |   754GB/88% |
+-----------------------+----------------+--------------+--------+-------------+

Note the log say the monthly job of Dec 1st was done but the list-archives of Affa do not show it!
Maybe it's a report bug only.

[janet]

jader

You really also need to show us the job Betty config details ie
db affa show Betty
or
cat /root/Betty.pl

My guess is you have 8 weekly backups retained, and until those "age" enough, they will not yet show up or be moved/renamed as monthly backups.
Look at the total picture of daily, weekly, monthly & yearly backups to see.

[Jáder]

Janet

Yes, I have long retention periods:

Code: [Select]

[root@leopardo affa]# db affa show Betty|grep keep -i
    dailyKeep=18
    monthlyKeep=18
    scheduledKeep=1
    weeklyKeep=7
    yearlyKeep=10

I just do not understood how long retention period affect generation of monthly/weekly backup.

I thought I could keep daily=30, weekly=52, monthly=18, yearly=10 wiht no problem.
Never thinked rename policy would affect what backups would be kept as weekly or monthly.

How should I use affa?
Maybe just daily=7 weekly=4, monthly=12, yearly=10 ??
I was keeping all those (day,week,month) 50% longer than a cicle (a week = 7 days, keep 10 days,; a month = 4 weeks, keep 6 weeks, ...)

So I think it was MY FAILURE to understand how things works.

Jáder

[janet]

jader

Yes, you have misunderstood what Affa is doing.

Affa archives use a FIFO principle (first in first out)
All backups are really daily backups, initially named as Scheduled backups.
As they age (ie reach the retention period specified) they are renamed to daily, then the daily are renamed to weekly, then as the weekly age they are renamed monthly, then as the monthly age they are renamed yearly, when the yearly retention limit is reached the archive file is deleted.
During that whole cycle some backups are deleted after their respective retention periods have been reached, but all backup archives are constantly being renamed, so that (after the retention period) every 7th daily becomes a weekly, every 4th weekly becomes a monthly & every 12th monthly becomes a yearly etc. The in between backups are deleted.

The need to restore data to a specific day, will determine the initial decision of how many daily backups you keep. If you need to be able to restore to ANY day in the last 28 days, then set daily retention to 28 days, & so on for weekly (say 4), monthly (say 12), yearly (say 2).
After 28 days you can only restore to the nearest week, after 4 weeks you can only restore to the nearest month, & after 12 months you can only restore to the nearest year.

I would think either 14 or 28 daily, 4 or 8 weekly, 12 monthly & 2 yearly. That should cover a wide span of time to allow adequate recovery from backups if necessary.
It really depends on your business model re backup & restore requirements.

Although all Affa backups are full backups (via hard links), they can be considered effectively incremental from a size usage perspective, so keeping additional daily backups does not place big demands on disk storage space.