FTP backup fails, BIG, with Backup Status: Success

[Michael_Oz]

Where to start...

I had not done a FTP backup since last FW upgrade to 6.9.3.

1. A new backup job, source FTP, PVR on local LAN, copied 26+1 files, then Completed, showing Success. There are 471 files at source.

2. Frontview job log shows failure on a specific file:

Failed to copy 20180525_2028_-_ABC_HD_-_ENDEAVOUR.eit

Yet the file was copied. (part of the 26)

3. Frontview Job log shows Success. Clearly not so.

4. Email message shows Success but does not show theoretical failure of the above file (or 6. below), so looks OK at face value. Yet >400 files not copied. Had there been a bunch more successful in the email I would not have scrolled down and noticed the problem. My next step would have been to format that drive...

5. Incorrect file name in destination.

The last file theoretically successfully copied, source name is:

20180525_2343_-_ABC_HD_-_PLANET_AMERICA.ts.ap

yet destination file is:

RICA.ts.ap

ie last 10 chars of name.

6. Above file theoretically successful, yet destination file zero length. (the +1)

7. Email is plain text but uses HTML Entity '>' for '>' char in job name.

Backup logs, email content, destination file list is attached. NO IT ISN'T - WHY DON'T YOU SUPPORT ZIP FILES? Give me an email address.

These are all BAD, but the worst, is reporting Success.

p.s. Both the files at 2. & 5. were copied to my PC OK via FileZilla.

I will retry, but I need to copy these files, an SMB backup is currently running.

[StephenB]

---

@Michael_Oz wrote:

NO IT ISN'T - WHY DON'T YOU SUPPORT ZIP FILES? 

---

They don't want full log zip files posted here (there is some privacy leakage if you post the full zip).  Blocking posts of zip files with spam/malicious content is an obvious concern.

Perhaps PM @mdgm-ntgr and ask if he is willing to look at your logs.  Generally they want the full log zip - either emailed, or a URL in a PM that can be downloaded (again not posted here).

[Michael_Oz]

After the SMB backup finished successfully, REALLY successfully, I reran the FTP backup (to a new directory & option set to full backup always).

The results are identical.

[Michael_Oz]

@Icewaterhot

---

Hi Michael,

1. Missing copy file problem we have fixed,Will be improved in the next version.

2. When we back up, the file name is too long to be renamed. We haven't reproduced it yet. How is it reproduced?

3. When doing a backup job, the email was sent incorrectly. Did you choose send full backup logs?

---

2.

This is standard Frontview FTP backup, from a Beyonwiz U4 PVR, linux based.

It has two ways of naming the TV show, one is very long#.

I had a problem on the NAS with long names, it would not delete the file*, so I changed settings to short a while ago.

There is a hidden .trash folder, which I was not expecting to be backed up.

It is possible a long format file was in there. None exist now (on that box) as it deletes old files.

I have another box with long names, so could try to reproduce it.

3. Yes, full backup logs was set.

# Example, one of the longest on the other box:

20160913_2028_-_ONE_CANBERRA_-_COPYCAT_-_AN_AGORAPHOBIC_PSYCHOLOGIST_AND_A_FEMALE_DETECTIVE_MUST_WORK_TOGETHER_TO_TAKE_DOWN_A_MURDERER_WHO_COPIES_SERIAL_KILLERS_FROM_THE_PAST__STARRING__SIGOURNEY_WEAVER,_HOLLY_HUNTER,_DERMOT_MULRONEY,_HARRY_CONNIC.ts.meta

* I had to delete the share to get rid of the long named file.

[Michael_Oz]

Note that there are now NO long filenames, I reran the FTP backup.

Same result.

[StephenB]

I don't normally use FTP backup, but I did test an over-the-internet backup a few weeks ago (remote source).  It failed to complete, but (unlike yours) gave a failure indication.  

So I think there likely are some bugs here (perhaps timeout related) that need to be isolated and fixed.