Closed danielporto closed 1 year ago
I have never used s3 before, can you provide a configuration of the wrong s3?
@danielporto ,
I see, this is the container startup verification, the container will try to connect to the remote storage and create the folder when it starts, if this operation fails, then the container will exit automatically.
What error are you trying to simulate?
Hello @ttionya thanks for your quick reply! The thing I'm trying to check is the email with the backup failure notification.
Despite the backup has been completed locally, the specific execution failed to upload it to a safe storage. In practice this failure can happen for a number of reasons such as wrong/updated keys, permissions etc..
What I expected to get is an email stating the failure (ideally the root cause, but Im ok with just a general failure). Thanks
The email will only notify you that the backup failed, without any error reason. At this point you should check the docker logs to determine the exact cause of the error. I want to keep the notification system simple.
The email will only notify you that the backup failed, without any error reason. At this point you should check the docker logs to determine the exact cause of the error. I want to keep the notification system simple.
sure thing. The problem is that right now I'm not getting any email at all. The system tries to backup but the container crashes without sending the failure notification via email. That's the point. I wish to get a notification because indeed the backup process failed.
It is because it does not pass the check at startup, and the container will start correctly only if the rclone configuration used can read and write to the remote storage correctly.
At this point it has not entered the backup process because it fails at startup. The working state of the container can be confirmed by docker ps
or docker-compose ps
or docker manager. And looking at the logs, you can see the red error message storage system connection failure [mys3:/mys3-keychain-backup]
.
I see. Basically there are two potentially different situations: 1 - the container starts-up with an invalid rclone config. The only way to overcome is to update the entrypoint to send the notification. (assuming the smtp configuration is also correct) 2 - the container starts up with a valid configuration but the connection is dropped somehow. So rclone will start but when the connection drop is detected some error will come out. This I did not test. Perhaps in this situation the notification is sent. That can be tested easily. I will do and report back.
Yes
1 - the container starts-up with an invalid rclone config.
The container will fail and exit (set to restart: always
and it will restart automatically) and the tool will not send any notifications. It does not enter the backup process at all, but uses the wrong configuration (and perhaps network errors, etc.) to detect that it cannot operate the remote storage properly, and it tells the user that the container has an exception by exiting the container with an error code (exit code 1).
2 - the container starts up with a valid configuration but the connection is dropped somehow.
As long as the container is started properly, it will perform backups at regular intervals according to the cron configuration and will also notify the backup results (MAIL_X
or PING_URL
is configured properly).
When I have the correct AWS ACCESS_KEY_ID and SECRET_ACCESS_KEY the backup is done correctly and I get an email to confirm.
However, if I set these two variables values to invalid ones, to simulate a problem I was expected to get an email informing that the backup has failed. However, the container crashes.
(note that the failure to find the rclone.conf is ok because im using envs to config and works when the secrets are set correctly)
Here is the output: