System Manager Backups Issue

[tdhaslett]

Hi All,
We need to change the folder on the remote server that our System Manager (8.1) is sending weekly backups to. I figured out that I can't change the existing job, but instead I need to delete the old backup job and create a new one, but that's where I'm having issues.

The SM backup has been running fine for the last 4 years, but we are restructuring our backup folder structure and need to change where they get sent to. Before deleting the old backup job, I tested an on-demand backup to the new folder, but it fails. It is going to the same device as it has for four years and those backups are still working, so there should be no issues between the two devices.

When I attempt to run an on-demand backup, it results in FAILED status with no explanation as to why. I am using SFTP for the transfer and the credentials always test successfully. When I run the backup, it will show RUNNING for a few minutes and then when I refresh it shows FAILED. There is no information in the log for the job about why it failed. It only shows the steps of creating the backup zip file.

How can I figure out what is causing the job to fail?


Incidentally, I also tried using SCP for the protocol, but every time I try it, it misinterprets the file name, and the job fails immediately. Is there a different way to enter the file name when using SCP?

 

[JefferP]

You didn't state what OS your b/u server was running. Most Avaya products struggle with a b/u server running Windows and prefer a Linux b/u server. If you're indeed using Windows (and stuck with it), perhaps SM doesn't like the directory structure you have for your new b/u location?? Just something to think about.

We're all ignorant, just in different subjects.

 

[tdhaslett]

The target is a share on a Synology NAS. It is the same device and share as the previous backups were sent to, just in a new folder structure.

I was able to get a call with an engineer from our MSP without them charging us $arm-and-leg and we got it sorted, but I still don't understand it.

As it turns out, for some reason the new job worked after changing the root of the backup path, even though it's the same device and share. The old backup path was "/volume1/share1/folder/filename" and the new path was failing when I set it to "/volume1/share1/backups/folder/filename". After changing the path to "/share1/backups/folder/filename", it worked. The engineer didn't really understand why it worked either.

At least it's working now.