Thanks Dave and Andrey
I think this problems is much more common than people think. I suppose that most of HD malfunction starts slowly and not at once. One block here, other there and it goes up to the point it really crashes or you detect when you need some file or folder and it is not there. Neither at backup.... always both are almost identical
On my case, it surfaces more as I have HDs with 1-2TB, with plenty of small text files, small images, many folders that are not so frequently acessed. Tipically a HD has about 1.5 to 2 million files. And this is not the first time I lost a BUNCH of files. This time was almost all HD, even with daily sync backups.
Follows a suggestion of implementation on SB. If it makes sense, that could change a lot the Market perception of SB.
1- the root problem: at backup time SB must to know if a diference betwen origin (oriHD) and destination (destHD) HD is due to intentional deletion or HD malfunction.
More specificaly: if missing files in oriHD compared with destHD are due to a delete operation or due to some directories that corrupted at oriHD.
2- I suppose that no hard tests or low level tools will be suficiently precise to indicate that resonably well that.
-------------- the idea --------
1- SB would have na optional resident module that intercepts (as antivírus does) any call to Windows deletion routine (probably na API?).
2- this residente module would log in a file anything that was deleted in the oriHD(one, more or all oriHDs).
3- when SB would be doing a syncronization backup (profile= delete files at destHD not in oriHD), when it sees that a file must be deleted at destHD (as it does not exists at oriHD), it will look at the "deletion log" to see if that file was deleted. If yes, it will be deleted at destHD normally. If not, it will record a warning at SB´s log and will not delete it.
4- so, my backup would be preserved, with no extra space lost!!!!![[-o<]( "Pray")
5- more than that, looking to SB´s log, we would be able to determine on the spot what file/área is starting to corrupt, and take necessary measures.
6- if 2brightsparks want to go further, a HD analysis tool could be done that shows many things like corrupted disk área, list of afected directories, etc.
7- I didn´t think all the details, but probably the deleted files log shoud be flushed after each backup or after a log analysis.
8- even if this procedure creates some overhead, I think is completely justificable. Did you check how much na antivírus take of resources? A lot!!!!
How it sounds?
Jose
I think this problems is much more common than people think. I suppose that most of HD malfunction starts slowly and not at once. One block here, other there and it goes up to the point it really crashes or you detect when you need some file or folder and it is not there. Neither at backup.... always both are almost identical
On my case, it surfaces more as I have HDs with 1-2TB, with plenty of small text files, small images, many folders that are not so frequently acessed. Tipically a HD has about 1.5 to 2 million files. And this is not the first time I lost a BUNCH of files. This time was almost all HD, even with daily sync backups.
Follows a suggestion of implementation on SB. If it makes sense, that could change a lot the Market perception of SB.
1- the root problem: at backup time SB must to know if a diference betwen origin (oriHD) and destination (destHD) HD is due to intentional deletion or HD malfunction.
More specificaly: if missing files in oriHD compared with destHD are due to a delete operation or due to some directories that corrupted at oriHD.
2- I suppose that no hard tests or low level tools will be suficiently precise to indicate that resonably well that.
-------------- the idea --------
1- SB would have na optional resident module that intercepts (as antivírus does) any call to Windows deletion routine (probably na API?).
2- this residente module would log in a file anything that was deleted in the oriHD(one, more or all oriHDs).
3- when SB would be doing a syncronization backup (profile= delete files at destHD not in oriHD), when it sees that a file must be deleted at destHD (as it does not exists at oriHD), it will look at the "deletion log" to see if that file was deleted. If yes, it will be deleted at destHD normally. If not, it will record a warning at SB´s log and will not delete it.
4- so, my backup would be preserved, with no extra space lost!!!!
5- more than that, looking to SB´s log, we would be able to determine on the spot what file/área is starting to corrupt, and take necessary measures.
6- if 2brightsparks want to go further, a HD analysis tool could be done that shows many things like corrupted disk área, list of afected directories, etc.
7- I didn´t think all the details, but probably the deleted files log shoud be flushed after each backup or after a log analysis.
8- even if this procedure creates some overhead, I think is completely justificable. Did you check how much na antivírus take of resources? A lot!!!!
How it sounds?
Jose