I wonder how this should work successful if Duplicati needs tons of local disc space for a remote sftp backup - means: it used local in addition the same size of disc space - before(!) it try to send the backup to the remote sftp-Server. This behavior goes totaly wrong since this would force the system to lost all free disc space if the compressed size of the files to backup bigger than the free disc space and could harm the whole system.
I have a 1TB disk and have to backup round about 470GB. Before I started there was 514GB free of disk. After starting the initial backup the free disc space reduced continuously - at the end are just 145GB free.
Also for my opinion the order of the backup build (1st. locale storage, 2nd. transfer only after the 1st step is completely done) expands the time usage extremely.
If you changed this to the total storage capacity of the backend, then this is causing your problem.
The remote volume size has nothing to do with the backend capacity, but this value defines the size of the files that are generated before they are uploaded.
Read this article for more information.
If you completed your backup using a huge upload volume size, it’s recommended to delete your backup and start over. The backup is safe and reliable, but all data is stored in one huge file.
If you want to restore a single file, Duplicati must download that huge file before the file can be extracted.
Hi @kees-z,
thank you. Yes you guessed right … So this solved the issue.
BUT: the label of the field guids the user to such wrong settings - since the label name - is in German "Remote-Volume-Größe“ translated to english "Remote-Volume-Size“ means you have to configure the size of remote target volume. Also the given additional information beside can not prevent this as they describe only that this setting have no effects to the maximum number of backups nor to the file size. In consequences nobody will read the hints which guided by the link but change the size setting.
