|OS type and version
I recently upgraded my virtualmin server to Debian 12 and uplifted all packages at the same time. Since upgrading backups have not been working. Backups were previously working with no problems for a long time. I am backing up one file per virtual server in the directory “/daily/%Y%m%d”. What looks to be happening is this directory is being created as a file as though the “one file per server” option is being ignored. If I create the directory manually before running the backup everything works as expected.
Has anyone else seen this? Has the backup mechanism had any changes in the last 2-3 months?
I assume you are in Virtualmin/Backup and Restore/Backup Virtual Servers?
Did this somehow get unchecked?
The box is checked and these settings have been working for at least two years and then stopped when I last upgraded things.
I have no idea if this is the issue or not but it looks like your Content Layout Control is set differently.
There have been some items that have not saved properly or have switched to default when this has been changed.
You might try unselecting the create destination directory checkbox, Return to Virtual Server List and then go back in and re-select it, just in case it is not set properly. I believe that most errors with the Content Layout Control button have already been fixed but maybe this is related? Just a guess.
Thanks for the suggestion but I have tried that and it still behaves the same. I even created a cloned job to see if that helped.
I have found if I mount my external storage via cifs the directory creation works as expected. SSH and FTP do not work. I can use a mounted directory as a short term fix but I would really prefer not to have the backup storage mounted directly on the virtualmin server so I do need to find a solution to this so I can revert back to SSH based file transfer.
no but your OS has Debian 12 was released 10 June 2023, so I guess your problem is related to your upgrade to Debian 12 (which is currently to fully supported, yet, by virtualmin) rather than the current backup mechanism. There is are a few topics on this forum related Debian 12 issues, it may be worth adding this issue there or creating a new thread with Debian 12 Issue, bug or not working in the title the staff may look at this more deeply
Thanks for the reply and I’ll add a reply to the Debian 12 FAQ thread I did have a read over prior to making this tread.
As for Debian 12 not being fully supported - it’s listed as a grade A supported system on the os-support documentation page
Fully supported doesn’t mean fully tested. Just way too many moving parts so things might break. But, that’s where open source comes in. All working to make it better somehow. I’m not sure what error logs to check though and I’m behind my other tasks and don’t have time to check.
I totally appreciate that and I’m a big advocate of open source software myself. At this point simply knowing whether ssh or ftp backups work on other Debian 12 systems will help me significantly. Roll back isn’t an option now and I do have a workaround so it’s not as critical as I thought 48 hours ago. That being said, nothing is a permanent as a temporary fix when it comes to IT
My main point is that if you can take the time to poke around the log files to see if you can find something it would be helpful to the developers. Over at unix dot com they are big advocates of learning and using rsync. I have NO clue what the underlying protocol is here.
I see. I’ve looked through all the log files I can think of (miniserv, the backup log, system logs, etc) and didn’t see any errors other than the backup log telling me it can’t write to the directory because it is a file.
The file test writes a file at the beginning, the backup script creates a file rather than a directory and then fails to upload anything. I’ll try to figure out how the backup process works at a low level and see if there is anything obvious in the Perl or CGI scripts.
It works just fine for me in Debian 12. I wonder if backup destination is set to
/daily/%Y%m%d/ does it change anything? Also, what destination mode set to? Is it Local file or directory?
Trailing slashes are removed when the settings are saved. The backup destinations of ssh and ftp fail to create the directory but local file or directory does.
An log when using SSH for a database backup ends with the error:
Uploading archive to SSH server <REDACTED> ..
.. upload failed! scp: realpath /db/20230828: No such file scp: upload "/db/20230828": path canonicalization failed scp: failed to upload directory /tmp/.webmin/594741-20230828 to /db/20230828
Backup failed! See the progress output above for the reason why.
I have tested it deeper with the code in Virtualmin 7.7 and latest checked in code and I could not reproduce this issue. The remote directory is being created as expected.
Can you provide more details about where exactly you’re trying to make a backup? The screenshot with all the options and the left menu visible would help.
Sorry, another stupid question but are you sure you are logging into your SSH server using the proper credentials for accessing your backup directory? Ie is the ownership of the directory correct?
I’m sure you’ve checked this already but just in case?
Sorry, just reread the original post and you say it does create a file in the location.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.