Relink not possible for Hyper Backup on Amazon S3 Glacier

[TorbenSchreiter]

Hi there,

the one remaining issue I have after moving all packages to M.2s is with Hyper Backup. I have a regular backup job configured to Amazon S3 (actually Glacier). After the package move it showed up red with a "Relink now" button. Whenever I press it, some process starts, runs for ~15-20 minutes with a progress bar actually step-by-step completing and afterwards the screen looks exactly as before (see screenshot).

EDIT. The Hyper Backup log says:

Error | 2024/10/21 18:08:39 | SYSTEM | [Amazon S3][glhv3-backup-s3-01 - Amazon S3] Failed to run relink task.
Error | 2024/10/21 18:08:39 | SYSTEM | [Amazon S3][glhv3-backup-s3-01 - Amazon S3] Moving backed up files from Amazon S3 to Amazon Glacier is not supported. Please restore files from Amazon Glacier via the AWS Management console.
Information | 2024/10/21 16:57:36 | SYSTEM | [Amazon S3][glhv3-backup-s3-01 - Amazon S3] Relink task started.

Is this an issue related to the the pkg move at all or shall I contact Synology support about it? What would I tell the support team what has happened? Some of the to-be-backed-up shared folders are now on a different volume. Is this the potential cause?

The source volume of the pkg move is, by now, deleted.

Cheers and thanks.

[007revad]

Some of the to-be-backed-up shared folders are now on a different volume. Is this the potential cause?

I would say, yes.

The source volume of the pkg move is, by now, deleted.

This will be a problem. DSM's @database folder would have been deleted.

[007revad]

It is possible that DSM only creates the web_packages folder when you install a package that needs it. The packages that I know create a folder in the web_packages folder are:

container manager
docker
idrive
joomla
kodexplorer
mediawiki
phpmyadmin
vtigercrm
wordpress

[TorbenSchreiter]

Thanks, I had Docker installed previously and will reinstall at some point in the future.

Ok to delete/rename /volume1/@database?

[007revad]

I'd rename it to /volume1/@database_bak just in case. If everyone is okay after a reboot, and DSM did not create a new /volume1/@database you can then delete /volume1/@database_bak.

[TorbenSchreiter]

Strange: after reboot it has recreated /volume1/@database even though the symlink is pointing to /volume2. Looks like it might actually still be using the one on /volume1.

user123@GLHV3:/volume1$ ls -l
[..]
drwxr-xr-x  1 root         root          32 Nov  9 20:27 @database
drwxr-xr-x  1 root         root         120 Oct 25 10:06 @database_bak
[..]
user123@GLHV3:/volume1$ readlink /var/services/pgsql
/volume2/@database/pgsql

[007revad]

/var/services/pgsql only relates to the pgsql folder (and contents) in the @database folder. As long as /var/services/pgsql is pointing to
/volume2/@database/pgsql then the postgress sql database DSM is using is on volume2.

DSM recreating the /volume1/@database folder is okay. DSM saves some other files in the @database folder on the lowest numbered volume, like:

/volume1/@database/autoupdate/syno-abuser-blocklist/ipblocklist
/volume1/@database/synolog/.SMBXFERDB
/volume1/@database/synologan/alert.sqlite

When I deleted volume1 DSM recreated those same files in /volume2/@database even though my postgress sql database DSM is on volume4.