Temp-Disk runs full during a big restore jobs

[helmut@pizka.at]

backup4all's temp directory runs full during a big restore job of some 100 GB .

The backup destination was a FTP server.
The backupset on the ftp server consists of 108 2GB .Zxx files (~220 GB).

It seems that backup4all fetches the backup files ( *.Zxx) to its local working directory
and does not delete them after being processed - that causes the free space on the disk to be
eaten up quickly.

See the situation during my test: there are already 26 GB of .Zxx files in the backup4all temp subfolders.
(see the attached screenshot).
[attachment=0]diskspace.JPG[/attachment]

I tested until the temp dir drive had 0 (zero) bytes of free space - causing the system to have
some problems ....

[Support]

Hi,

The zip files in your case are not independent, which means all 108 zip parts (z01, z02...) must be downloaded and only after that, they will be extracted.

[helmut@pizka.at]

This may be a technical explanation but it does not help.
Inseat this would mean that I have to reserve a temp area as big as my restore set .
Just consider If it's not 200 GB but 1 TB ?

What can I do to solve this unsatisfying situation ? Use smaller zp files ? .... ?

[Support]

Hi,

In such cases, you should use independent splits option from Backup Properties->Compression page.
This way, when you restore a file (or several files), Backup4all will download and extract only the splits which contain the file(s) you need.

[helmut@pizka.at]

Hi,
I tested with a new big backup with independant ZIP's - but the restore still filled up the TEMP.
I also installed the lasted update.

So - what can we do -if a big restore does not run seamlessly - the program is not realy relyable.

Please help.

[Support]

Hi,

Please let us know:
1. Did you restored a single file or the entire backup?
2. How large was the split size you set?
3. How large was the file you wanted to restore?
4. How much free disk space you have on C: ?
5. How large were the zip files restored? How many splits were?
6. We are also interested of the restore log.