Showing results for 
Search instead for 
Do you mean 
ACSoft_P...

Villager

(1)

Duplicate

Sort transfered files by reverse file size !!!

When MozyPro transfer files to your servers, it would be a great idea to sort transfered files before to transfer them,

so that smaler files get first in queue list of files to transfer.

 

Doing so will permit to transfer the maximum number of files in the shorter possible time to your servers,

and put the biggest files at the end of the queue...

 

For example : Mailbox database.edb which is in general a huge file to transfer,

and that block the transfer of smaller files that are more important for the customer.

 

Regards.

Christian ALLEGRE.

AC Soft.

0
Comments
Owyn
Overlord Level 2

(663)

If they do so then it would take ages cuz now It transfers all the big files first and say that 99% backup completed in an hour and then it transfers last percent ( all the small files ) which takes ten more hours, I don't want it to be reverse - wait 10+ hours for 1% to complete then get last 99% in a hour or less

ACSoft_P...

Villager

(1)

What???? On my experience, transfering a huge file like Mailbox database.edb may take more than one day !!!!

So, all the small files are waiting int the queue, and are not backed up while Mailbox database.edb transfer....

 

And I repeat : Small files are often more important for customers (bill, word docs, excel documents, etc...) which are all small files that customer spent many hours on...

 

So, I vote for Smaller files FIRST !!!!

 

Owyn
Overlord Level 2

(663)

You probably have pretty low internet speed or your database file is over 100+GB and changes a lot -  so it takes longer to upload than to encode large bunch of small files. On my experience it took a hour or two to upload a thousand of files total of 10+GB and 15+ hours to transfer 10+ thousand of small files about 1 GB total.

 

Though even if your database is larger than 100GB it shouldn't be completely transferred again to mozy every time, just changed parts of it so it shouldn't take long, I'm backing up a sq3 database total of 20MB to mozy and daily it transfers just 2MB of it to mozy for it to be backed up.

 

However feauture looks needed but probably not as simple as this, upload priority for backup sets (folders)  would be better I suppose.

ACSoft_P...

Villager

(1)

Well, my customer have a 100b/s upload speed ADSL connexion, which is enough for the normal trafic of 1 to 2Gb used every night.

 

I agree that in a normal situation, where Mozy servers have all the customers datas, then, you should NEVER have to transport huge files. So, file size sorting is not very important in that case.

 

But i'm experienced the fact that, when i updated the MOZY Client to Vxxx.115, and then to Vxxx.125,

it decided to transfer again that huge Mailbox database.edb file (which is 7Gb big).

 

So, except on the initial upload, where order has no importance, coz all the files have to be first backuped,

it would be preferable to put huges files (huge = much more bigger than the average file size in the list) 

at the end of the queue,

so that the queue will be emptied with the MAX number of files transfered,

instead ofthe MAX number of byte transfered (which is the case when big files are transfered first).

 

The important thing is the file, not the byte saved.

 

:smileyhappy:

 

ACSoft_P...

Villager

(1)

At least, it would be a great idea to give this choice (large files first or last in queue) to the user.

Fryer
Employee

(591)

Status changed to: Being Discussed
This is kind of funny. We used to do it this way, small files first, a long time ago, and we got a lot of complaints and so changed it to the current 'no order' backup. This really would be solved by a priority setting. For the case of one super large edb, could just set the priority to low so everything else gets backed up first. Those files you want at the top of the backup, set to high. This has been discussed before, and we'll do that eventually.
Fryer
Employee

(591)

Status changed to: Duplicate
I'm closing as a duplicate of priority backup order.