Recently (on a newer installation), I imported a few domains individually (either by import and/or manually create then restore them), no issue.
Today (maybe since the 2.1.2 upgrade?), when I attempt to use the /import.php function - I get “The connection to the server was reset while the page was loading” in FF and a generic DNS “cannot find server” error in IE.
The destination box is one local to me (and created by me) – so the /tmp directory could have been created to whatever size needed (had I been clairvoyant … )
Is there a recommended by IWorx if:
you have the ability to create the /tmp directory, what size is preferable?
you’re located in a DC where the /tmp directory would be pre-set and not in your control, the best way around this potential issue?
Hard to say JB. For our boxes, we usually use 2GB for /tmp. However, we’ve seen backups much larger than 2GB, so this isn’t the “best” way to solve the problem of large backups.
If you open up /home/interworx/iworx.ini, look for the [dir] section, and then change the line:
tmp="/tmp"
to another directory on a bigger partition. For example, if /home was your biggest partition and you created /home/tmp, you would change the line to:
My temp directory does not seem to be it’s own partition – just a directory within “/”
I only have 2 mount points “/” = “/dev/mapper/VolGroup00-LogVol00” (111GB Free) and “/boot.” (This was originally built as a test box, and now is becoming my repository for sites that are in the midst of a migration from one box to another).
Does it seem that in this scenario I should be out of space for the backup?
No, that should be far more than enough for a ~350MB backup. Are you using the mass transfer option, or are you doing a single account import and uploading the backup from your local machine?
Ah, ok, this is most likely the problem. There is a max filesize limit that both Apache and PHP impose, and there is also a script max execution time value for PHP. I’m guessing that one of these 3 limits got reached as you were trying to upload the file (my guess is the PHP max execution time). Try ftp’ing the backup up on to the server into a directory (like /tmp), and then use the single account import, and instead of using the local import method, use the “remote” import method and specify the full path to the backup file (e.g., /tmp/domain.com-mar.06.2006.tar.gz)
By the way, FTP-ing the file to the server, then importing solved my problem.
I think what confused me about this is that the faliure when importing from Local Backup is immediate, rather than the import starting and then hanging, timing out, or not finishing, etc.
Adding a note about this on the “Quick Help” for Local Backup may help to keep someone else from stubbing-their-toe on this one.
Yeah, this was because the backup file never finished transferring to the server, due to the various timeouts I mentioned. As such, the import process never really started in the first place.
Agreed, and honestly, a lot more than just editing the Quick Help needs to be done to make that page less confusing. We’re working on it.