recover directory from backup?

[thisisit3]

Guys, I need some help. I accidentally deleted a directory from my server (which is under /home/domain/public_html/) and I need the entire directory recovered.

I've already opened a support ticked, but is there anything else that I can do?

I know there is no "undelete" function... so I guess my only help is a recent file backup.

Thank you.

[Ron]

Oh craaap. I don't know if this will be anything that helps, but I once lost 14 days of data from my database; I was able to recover most of it from Google's cache.

A FEW of your most recent changes might be in .vim_history (or similar) albeit in a cryptic format.

Sorry you're dealing with this.

[thisisit3]

It is an unfortunate event and as hard as it may be, Jag has great support and they are restoring the entire directory tree right now.

Hopefully the backup isn't too old (maybe a few days old?) so I hope I haven't lost too many things.

I'll update this post once the process is complete.

[Ron]

Yes, I've had them restore a vandalized database once, too. $15 is cheap insurance, and the date on the database was irrelevant.

The first one was a server wide event and they could only restore back 2 weeks old, so I scrounged around for most of the data. Now in the big scheme of things it was a pretty minor thing, but at the time it was a significant portion of my data.

I was thankful I didn't lose too much code.

[JPC-Sabrina]

Top notch hosting companies like Jaguarpc.com can almost always restore your data for a small fee. I agree with Ron. Paying a small restoration
fee is not unlike insurance. In some cases you might lose hundreds of hours of work that would cost you an enormous amount of time and effort to recover.
Recovery fees are very affordable in my opinion.

[excalibur]

Two days ago the whole public_html content in one of my sites vanished. We all know that nowadays Jag support is somewhat slow but eventually they restored it, and nothing was lost. Maybe you need to knock the door twice before they answer.

[Ron]

Top notch hosting companies like Jaguarpc.com can almost always restore your data for a small fee.

Yeah, but it would be great if the the backups are current. Judging from posts on the forum and my own experience, far too frequently current JAG backups are corrupt.

I'll be happy to see a new setup for the cloud.

[thisisit3]

I am not sure what I happening, Jag restored the missing directory (about 4GB of data), things were back to normal and then the directory disappeared. I know that I didn't delete it by accident like I did before. I've requested Jag to give it another try and I'm waiting for their reply.

PS:
Maybe some bug or incompatibility in the backup software?... anyone seen this before?

[Ron]

Hmmmm, that is very weird. Maybe there is a possibility of a RAID issue, but I'd also be looking for an intruder or software bug other than JAGs.

First thing after the restore, make a local copy outside of your web space!

[thisisit3]

I think I've traced the problem to buggy software. Apparently, when someone does file_exists() in PHP, the function returns true even if the argument is not a file, but a directory! Thus, the software deleted an entire directory with 4GB of data.

So two key events took place:

1) The file_exists() function returns true on directories
2) The software itself wrongly put as an argument a directory and not a file (because the file didn't exist in the first place).

So the result was: file_exists() returned true, the software then proceeded to delete the entire directory. The fix is easy, first we replace the file_exists() function with is_file(), which doesn't return true on directories and then we also make sure the function is never passed a directory.

[Ron]

Wow. Good catch. I will remember that!

My next thought was "How the heck was the software doing a delete of a non-empty directory by accident?" Does unlink() also work the same as rmdir(), or does the software later determine filetype after being passed filepath?

[thisisit3]

The parameters passed to file_exists() were like $path.$file and $file was empty, thus file_exists() was passed a path only and returned true, then onwards to a delete function.

[Ron]

I guess that means the delete function is determining filetype in some manner, using unlink() or rmdir() as appropriate. Or both. Which was unfortunate.

[thisisit3]

Thats correct, because the whole delete() function on my application works like this:

1) SQL is initiated with START TRANSACTION
2) A random temp directory is created under the tmp dir
3) The relevant files are moved to the temp directory
4) SQL delete and relevant queries are executed
5) If all of the above is successful, then the whole temp directory is deleted and SQL "COMMIT" is executed
6) If NOT all of the above is successful, then the temp directory is moved to its original location and SQL "ROLLBACK" is executed.

Thus, I have combined SQL and File structure safety. Too bad the file_exists() is such a bad function to use.

[Gwaihir]

Yeah, you probably ought to use is_file() instead.