This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Backing up (and restoring) a Plone instance
We have been backing up our Plone folder (the entire folder and not just filestorage and blogstorage or data.fs) every night. We did not stop the Plone process before doing a rsync of the Plone folder to our backup server -- because we have not launched our site yet and nobody is accessing it at night.
When we tried to restore Plone from a backup, i.e., remove our existing Plone folder and copy the entire backup Plone folder into /usr/local/ and then run /usr/local/Plone/zinstance/bin/plonectl start, Plone started successfully but we got various types of errors when we went to the site. Some images became missing with error like "blob file misisng" (cannot remember the exact words). Also, when we tried to Edit our News folder (or collection), we got this error "Macro querywidget does not exist for ". Other errors include "ValueError: Unable to find update_version_before_edit".
According to this documentation http://plone.org/documentation/kb/backup-plone, backing up Plone can be as simple as copying the data.fs folder. So our method should work. Is there soemthing we are doing wrong here? Is there a cache we are supposed to clear or a catalog to re-index before we can run a restored Plone folder? Or are we supposed to re-install Plone and then copy back the backup filestorage and blobstorage folders (this is what we do whenever we upgragde Plone)?
Thank you very much in anticipation.
cmgui
As the document you reference states: "If you're using BLOB storage (which became a default in Plone 4 for Images and Files), you'll have to backup also the blob-objects. They are stored by default in the var/blobstorage folder of your buildout." It's not just a matter of copying the data.fs file.
Here is a very extensive documentation on doing backups for Plone:
http://www.plone-entwicklerhandbuch.de/plone-entwicklerhandbuch/produktivserver/backup-der-zodb
Use Google Translate if you can't read german...this is all working in production with Plone 4.X.
Related
I recently started working with SVN, I am using it in combination with Wordpress.
I just made a number of updates to Wordpress and to some plugins, and I would like to know in what order I need to update, or whether it even matters.
Here is what I did:
Locally on my computer:
svn delete folder xyz
commit the deletion
add a new folder by the same name
svn add the folder
svn commit
Now if I log in to our development server, do I just to "svn update" ?
Or do I need to go through the various versions by updating to specific version numbers?
The reason I ask, is because I have had one or two tree conflicts in the past where I got:
Tree conflict (local dir unversioned, incoming dir add upon update) for location wp-content/plugins/ExamplePlugin/ExampleSubDir
Does my workflow lead to such errors? Am I overlooking something?
Your workflow is fine, and yes, you would just perform a single svn update on the other computer to get fully up-to-date.
The workflow you describe would produce a tree conflict if you happened to have an unversioned folder named "xyz" in the same location as the one you just committed (which is what the error says in the parenthetical remark). You should remove that unversioned folder and then let SVN add that folder itself (via the call to update).
If you haven't already, it might be worth reviewing some of the documentation to ensure you understand the fundamentals.
My company has a nexus installation that grew to a rather huge size on disk, thus I am in the process of cleaning it up. While doing so, I found a directory called storage_full in the sonatype-work/nexus directory, adjacent to the storage folder, which is not listed in the nexus directories documentation. Google finds nothing either. The folder is rather large and seems to be similar to storage in structure.
Questions:
What is the use of this directory?
Can I delete it, or clean it up? I'd rather not use trial and error to find out if it's important as any downtime of the service is unacceptable.
The nexus version is 2.11.2-03, but AFAIK it has been repeatedly updated and was running in the same work directory since about 2011 - could it be that this folder was left over from an older version?
Nexus has never had a directory called "storage_full" as part of it's setup, so I'm not sure what this is. Check to see of the local storage location of any of your repositories has been overridden to point to that location.
I am in the process of migrating a D7 site from one server to another. I have successfully exported and uploaded the settings to the new site using Features, but I need to get the content over to the site as well. I've been looking at several modules to try and solve this problem, but I have not found anything suitable for this task. Please let me know if I am overlooking a really simple solution.
Thanks!
Mark
Easiest solution is to export a database dump and import it into your new server. You can do it wotj phpMyAdmin but I recommend using Drush.
This way you can simply do a database dump via:
drush sql-dump > ~/sql-dump-file-name.sql
and later import via:
drush sql-cli < ~/sql-dump-file-name.sql
Also copy your files directory from old server to new server which is located in /sites/default/files.
I've successfully used the backup and migrate module for these tasks. True, creating a dump and then spooling the dump into the other database works, but this typically also copies all caches.
The backup_migrate module allows you save backups on your local server, but also to your hard disk, from where you can upload it again to the other site.
A neat thing here is that you can exclude tables, such as cache tables, which makes the transfer much faster.
Obviously you need a core installation on the other end, and the backup_migrate module already installed for this to work, but I assume that since you only ask about the db, you must have mirrored the file structure already (excluding the settings files).
I uninstalled and reinstalled my WAMP earlier today. I backed up my /www directory but totally forgot about my database (phpmyadmin). I didn't delete my C:/wamp directory, i just reinstalled on top of it.
Does this mean my databases are gone forever? Is there a way to retrieve them? Next time i'll know to export a dump of my databases before I meddle with the installation, I guess I had to learn this the hard way...
Thanks for your help.
That depends if you deleted the data directory or not. By default, wamp's data directory is c:/wamp/bin/mysql/mysql5.x.x/data check there and see if you have some folders with the names of your old databases. In those folders there would be a bunch of .frm, .MYD, and .MYI files assuming you are using myisam. If those files exist then you can recover. Just make sure the datadir in my.ini is pointing to the directory where your database are and restart mysql. It should fix itself automatically.
If you use innodb tables then it's a little more complicated but can be done. Those would be stored in files named ibdata1, ibdata2, etc.
If you don't have any of those files then I'm afraid you're out of luck.
I was able to retrieve mine on windows 7 by doing the following
Open Computer by clicking the Start button , and then clicking Computer.
Navigate to the folder that used to contain the file or folder c:/wamp/bin/mysql/mysql5.x.x/data
Copied it just in case I needed to revert
Right-click it, and then click Restore previous versions. ...
Double-click a previous version of the folder that contains the file or folder you want to restore.
I have been developing a Drupal 6 site on my PC using XAMPP. I'm done now, and everything looks peachy.
Problem is, I need to put all my content (including custom modules and themes) up onto a staging server which only has a fresh Drupal 6 install on it. I can't imagine having to set up all my custom content types and whatnot all over again on the staging server.
So I ask, how does one go about doing what I need to do? Which is essentially duplicating my Drupal install from my PC, to the staging server.
The staging server is running Linux, and I develop on a Windows PC, if that helps.
Thanks in advance.
Copy up all the files from development to live, and mysqldump your database and run that on the live server. Then all you have to do is change the settings.php file to point at the right database, if for some reason 'localhost' is not also your mysql database.
The quickest solution is probably the backup_migrate module. It is only a tool to copy your database. You could also use phpmyadmin or similar instead if you wanted. The backup_migrate module do have some good defaults settings as to which tables to skip (like cache tables). All the settings etc. that is not defined in code is stored in your db. So you only need to copy the db to be set. You can choose to exclude some tables, like the node or user table if you don't want to bring over your test data.
If you don't use subversion, then you gotta manually copy the files (rsync, scp, whatever) and the db (mysqldump).
what we usually do is have a hierarchy of independent subversion repos as follows:
core
sites/all/modules/contributed
sites/all/modules/custom
sites/all/themes/ (we develop our own and don't use contributed themes)
sites/all/libraries
then we use the svn:externals properties so that if you check out "core" you get every associated repo.
we got about 2 main developers with 4 other guys that may also contribute code to the site. each have their own local dev environment and we all got a common sandbox - where we make sure the stuff we wrote doesn't break someone else's module (it has happened before!).
we use svn commit hooks to update the beta/staging/sandbox site upon commit.
with all that setup, [re]deploying a site is a simple matter of going to the proper folder and issuing a "svn co http://repolocation/reponame ." and then updating the DB.
two last things to consider:
we are moving from svn to git
the features module will allow you to save changes you make to your own modules (views, content types, etc) and package all that into a deployable module so you don't have to duplicate your efforts. we are also looking into using this for ourselves.
I hope this helps you.
I second using backup_migrate. It's great.
When I'm installing a fresh site from development to production, I:
backup the site using backup_migrate module
copy all the files up to the server
edit the sites/default/settings.php to have the right database path and account info
do an import of the last backup_migrate dump (usually using mysql < backupfilename.sql, unless I already have drupal setup and have backup_migrate installed, then I use the GUI
But take a look here for the official version:
http://drupal.org/node/776864
Now, you didn't ask, but when the site is live and users are contributing content, moving future development versions of your site from development/staging to production without blowing away live content is a whole different problem, and one that Drupal doesn't have a good answer for...
Andy-