I'm using Apache 2.4 on Ubuntu 14.04 and Drupal 7. I wanted an easy remote backup for my Drupal site, so I tried putting it in Dropbox. Then, something happened, and Apache started giving 403 errors ("You don't have permission to access / on this server.") for the site.
I recovered from an old backup, but I still can't figure out what happened. I diffed the Dropbox directory and the backup, and they're the same. I reset all the permissions in the Dropbox directory to match the backup, but the version in Dropbox still won't work. I also tried copying the files from the Dropbox directory into the location of the backup, and that still didn't work.
I'm a bit at a loss as to what went wrong. Does anyone have ideas as to what Dropbox might have broken?
Rather than trying to run the site from a Dropbox location, why not just make Dropbox the repository for backups?
Try this:
https://www.drupal.org/project/backup_migrate_dropbox
This will also backup your database which you didn't mention as part of your Dropbox backup strategy.
Or you could run a cron task to run incremental backups via rsync to the Dropbox folder (Assuming you have already gone through getting Dropbox connected any syncing with Ubuntu). I use the process documented at this location and it has worked perfectly on a number of different web servers:
http://hadzimahmutovic.com/rsnapshot-mysql/rsnapshot-backing-mysql-databases
Related
I am quite new to server migrations, but fairly familiar with cPanel though. My current task is to migrate an entire website from a server with cPanel to another one.
What I did so far:
Use the Backup Wizard on the old server to create a full backup archive, and FTP it to the new server.
The full archive (about 6 GB because there are a lot of images) is now in my new server's public_html directory.
Now, what I need is a way to make the server take this tar archive, which is a full backup, and restore from it.
What I tried:
I tried simply extracting the archive, but it is taking forever to finish (again the archive is 6 GB), and for some reason my browser tab has to stay open until the end of the process, otherwise the extracting halts.
Also, as I have WHM access, I tried the "Restore a Full Backup/cpmove File" option, but for some reason, under the "Username for the account that you wish to restore:" textbox, WHM does not find my cPanel username.
If anyone can either tell me what I am doing wrong, or propose another option, I would really appreciate it.
P.S.: I only have WHM access to the new server, not the old one.
Edit: I got the WHM method working now. My mistake was that my tar archive was not stored in the /home directory, but in the home directory of the cPanel user (which is /home/username)!
Move your cpanel full backup file to /home directory and if you root have access of the server use below command as /scripts/restorepkg (cpanel username )
OR
Login to WHM with root user and go through the steps mentioned on below URL.
http://documentation.cpanel.net:8090/display/68Docs/Restore+a+Full+Backup+cpmove+File
I had a shared hosting package with 1and1 and I just moved over to their VPS hosting that uses Plesk. I already had the domains moved over the VPS server and I already uploaded all of the files via FTP.
I talked to an agent yesterday and he helped me setup the main page on the website so that it would go to the appropriate root directory. The main website is working properly whenever I go the main domain name, however, whenever I go to website.com/blank or website.com/stuff, I receive a 404 error.
The strange part is that I see the files in Plesk file manager, I just don't know why they are not displaying properly. I didn't change anything in the migration process.
I did not change the code on any of the pages and I have contacted their customer support team a number of times, but they have been unable to resolve the issue.
Can anyone tell me what I should do to make sure that the files are associated with the correct pages?
Have you checked the permission for the files and folder under your domain, this seems to be an issue with either your ownership or permission of the files. And if thats not the problem it could even be your .htaccess file.. make sure you have transferred your .htaccess file as well from old shared hosting to new VPS.
I am about to install Maverick and before I do that I am going to reformat my macbook air. I use dropbox and have about 15gb of (small) files on it (mainly documents/ebooks).
My question is: Is it possible to backup my Dropbox folder now, reformat my SSD and and install dropbox again. After wish I replace the dropbox folder with my backup without getting Dropbox confused (It might think it are new files? So dropbox could upload them or/and download the same files again).
Does anyone got any experience with this?
It's fine to do this - I have done it myself, but not on OSX.
The Dropbox client will index the files that it finds on your computer and compare them to the ones which are already in your account (on the server). I believe that it uses some kind of hash function to do this - the client creates a small hash value for each file and then this value is compared to the value on the server. If the value is the same then the client assumes that the file is the same and it does not need to be re-uploaded. However, if you have thousands of files, this can take some time.
Source: https://www.dropbox.com/help/1941/en - "The application will index the files and see that they are the same files in your account."
If you want to do it, when you install Dropbox again, you should sign-in to your account, let it create the Dropbox folder and then click "Pause Syncing" so that it doesn't start downloading everything. Then you should copy the backed-up Dropbox files into the new Dropbox folder and resume syncing.
Thanks in advance for any help, you guys are awesome!
A previous web developer made a backup of the site in question to the server months ago, and the permissions for this backup are 600. I can't change the permissions or download the file, although I can still move it between folders.
I've read having low disk space is sometimes the problem, but in this case there are 2 GB left, so that should be fine.
There is an other way to download backup from server to local machine, if you are able to move backup file in folders then move it to your website's home directory like '/home/user/public_html/backup.zip' and then browse it in browser and download the backup file.
http://yourdomain.com/backup.zip
It will provide you download option.
The title doesn't really sum it all up...
I have recently installed ModX Revolution 2.2.4 on an Apache server and I am having complications with the cache folder. Occasionally I have to manually clear the cache folder via ftp, but any files written there are owned by Apache and my account can't delete them. I have tried adding the "new_file_permissions" and "new_folder_permissions" to the system settings, but there is no change. The cache files are always owned by Apache and I have no access via ftp.
Also, files such as the .htaccess and really anything I upload (css etc) are seen as uneditable to modx unless I manually change them to 777 via ftp. I can't change owner and group though.
The server tech can't figure it out. This has come up before on the modx forums but it has never been answered.
Obviously, this is a server problem.
I had this problem (with an IIS server though), and the host needed to change some of their settings.
Especially, if MODX works on your different host(s).
That is the way it is supposed to work, your FTP account does not have permission to write files written by apache, your ftp may be a member of the group but does not have write permission. [needed to delete]. I suspect this is by design for security purposes.
Your new_file_permissions, new_folder_permissions are used for the modx file manager.
So you can do a couple of things:
Run modx under fastcgi, that way the user writing the files should be the same user as the ftp user.
OR
write a little script [you can even stuff it in a snippet] that will delete the cache files for you. [since it will be running as the apache user, it should be no problem.