サポート » インストール » WordPressの復元方法について

  • 解決済 tom angle

    (@tom-angle)


    お世話になります。

    WordPress 4.1から最新版にバージョンアップしたところ、一部プラグインがうまく動作せず、とりあえず、元の環境に復元したいのですが、いくつか教えていただけないでしょうか。

    Q1.バージョンアップする前に次の方法でファイルとデータベースのバックアップを取りました。復元の準備はこれだけでよかったのでしょうか。

    1.FFFTPでホストのディレクトリ WWWの下にあるすべてのフォルダーとファイルをダウンロード。
    2.PhpMyAdminでデータベースをエクスポートして.sql ファイルにしました。このときは、デフォルトの設定で何もオプションをいじっていません。

    Q2.次の方法でバージョンアップされているホスト環境を元のバージョンに復元しようと思います。これで正しいでしょうか。

    1.ファイルを復元する前に、バージョンアップされいるホストのWWWW以下のファイル、フォルダーをすべて削除する。
    2.FFFTPでローカルにダウンロードしたすべてのファイルをWWWの下にアップロードする。
    3.PhpMyAdminでエクスポートした.sqlファイルをサーバーにインポートする。

    Q3.PhpMyAdminでインポートすると、すでにその名前のデータベースがある、という趣旨のエラーが出てインポートできません。 上書きすればよいのでしょうか。 しかし、その方法がわかりません。ご存知ないでしょうか。

    Q4.FFFTPでファイルをアップロードすると、ファイル、フォルダーの属性値が以前と変わってしまいます。たとえば、WPフォルダーは、元は、rwxr-xr-x であったものが、rwx—r-x になってしまいます。
    これは、そのままで問題ないのでしょうか。 もし、問題ある場合は、どうすれば大量のファイルの属性を正しく元に設定しなおすことができるのでしょうか。

    Q5.もし、上記の方法でファイルをデータベースが元に戻った場合、特にトラブルがなければ、このまま以前と同じように動作する、と考えてよいのでしょうか。あるいは、絶対にやらなければならない他の作業がありますでしょうか。

    どうぞよろしくお願いいたします。

15件の返信を表示中 - 1 - 15件目 (全16件中)
  • kautakku

    (@kautakku)

    この状態でしたら、確実に失敗します^^;

    画像やプラグイン・テーマフォルダまで削除する感じになってるからです。

    .sql ファイルは確実に復元できますか?できない場合を考えるとオススメできません。削除してからインポートする感じなので。よくわからない場合は触らない方が良いと思います。

    FFFTPでファイルをアップロードするとき、属性が変わるとエラーが出るファイルもあるので、オプションの転送3をチェックしてrwx—r-x限定するような指定を解除してください。

    その後、テスト環境を作成してキチンとアップロードしてパーミッションが変更しないかチェックしたほうが良いですよ。

    古いバージョンを使うデメリットを考えたら、動作する代替プラグインを探したほうが良いと個人的に思います。

    tom angle

    (@tom-angle)

    kautakku さん、ご回答ありがとうございます。

    >この状態でしたら、確実に失敗します^^;
    やっぱり、そうなんか・・・

    具体的にどの部分が問題なのでしょうか。WWWW以下をすべて削除する、という点なのでしょうか。
    別のサーバーに引っ越しするのと同じだろうと思っていたのですが・・・・そもそも別のサーバーへ引っ越しする場合は、この方法ではダメということなのでしょうか。

    新規のWordPressの設定は行ったことはあるのですが、別サーバーへの引っ越しはバージョンアップははじめてで基本的なことがよくわかっておりません。 
    データベースとファイルをそのままコピーすれば、基本的にOKと思っていたのですが、そうではない、ということでしょうか。 申し訳ありませんが、ただコピーすればよいわけではない理由はなんなのか教えていただけないでしょうか。(たぶん、その部分が私の理解に大きく欠落している点だと思います。)

    お手数をお掛けして申し訳ありませんが、ご教授お願いいたします。

    munyagu

    (@munyagu)

    こんにちは

    Q1
    正しいです。

    Q2
    それでも出来ます。
    しかし、WordPressインストール先のwp-adminディレクトリとwp-includesだけを以前のバージョンで上書きし、WordPressのバージョンをダウングレードする方法をまず試してみてはどうでしょうか。
    小さいリスクで済むと思います。

    Q3
    Q2とも関係がありますが、アップデート失敗でデータベースを戻さないといけないケースはあまりないと思います。
    (※以前の投稿状態とか設定状態に戻したいなら別ですが)
    WordPressをバージョンアップするとデータベースもバージョンアップされますが、4.xの間ではテーブルレイアウト自体に問題になる変更はない気がします。
    確信はないですが・・・

    Q4
    上記の上書きではパーミッションは変更されないと思いますので、問題ありません。

    Q5
    他にはダウングレードごとに毎回必ずやらないといけないものはないと思いますが、「このまま以前と同じように動作する」かどうかについては、動作確認して判断するしかありません。

    tom angle

    (@tom-angle)

    munyaguさん、いつも明快な回答をありがとうございます。

    アドバイスを参考にやってみます。 ありがとうございました。

    munyagu

    (@munyagu)

    すいません、ちょっと間違えました・・・

    WordPressインストールディレクトリ内にあるfunctions.php、wp-activate.phpなどのファイルも以前のバージョンで上書きしてください。

    要するに、wp-content以外を以前のバージョンで上書きしてください。

    すいません。

    tom angle

    (@tom-angle)

    munyagu さん、

    補足のアドバイスありがとうございます。 助かります。

    kautakku

    (@kautakku)

    具体的にどの部分が問題なのでしょうか。WWWW以下をすべて削除する、という点なのでしょうか。

    一番大事なファイルがwp-adminフォルダ間違えました。同じ階層にあるwp-config.phpですが、そのファイルの中身が変わってしまうとサイトがキチンと表示されません。

    ほかは.htaccessに記載があると、それもデフォルトの状態にもどってしまいます。細かいところではrobots.txtを編集されている場合もですし、wp-cron.phpの設定をしている場合も同様です。

    完全に復元できる状態を作ってから作業しないと、数日間泣きそうになる姿しか浮かばず…

    その状態でオススメできないな…と思って、別の提案をさせていただきました。

    • この返信は9 ヶ月前に  kautakku さんが編集しました。
    tom angle

    (@tom-angle)

    kautakku さん

    アドバイスありがとうございます。

    >ほかは.htaccessに記載があると、それもデフォルトの状態にもどってしまいます。細かいところでは
    >robots.txtを編集されている場合もですし、wp-cron.phpの設定をしている場合も同様です。

    一応wwwの下のファイルをすべてダウンロードし、それをそのままアップロードするので、ご指摘の
    のファイルもすべてバージョンアップ前の状態に戻すつもりです。
    ご指摘の点も注意して整合性を確認してすすめたいと思います。

    今後ともどうぞよろしくお願いいたします。 

    tom angle

    (@tom-angle)

    お世話になります。

    元の状態に復元しようとしたのですが、バージョンアップ前のデータベースのエクスポートファイル(.sql)が壊れていて復元できませんでした。 実は、このサーバーは、テスト用のサーバーです。

    アドバイスを参考に本番サーバーの内容をテストサーバーにコピーして元の環境を復元することができました。 ところが、よくわからない状態になってしまい、とても困っています。

    問題: テストサーバーでは、正常に管理画面にも入れたようなのですが・・・ この管理画面が本番サーバーなのか、テストサーバーなのか 判別がつかなくて困っています。

    やったこと:

    1.本番サーバーからファイル、データベースをテストサーバーに移した。
    ここで、本番を honban.com , テストサーバーを test.com という仮名で以下を説明します。

    2.searchreplacedb2.phpを使ったテストサーバーのDB内の本番ドメイン名をテストドメイン名に変更した。
    3.テストサーバーのwp-config.php をテストサーバーのDB情報に更新した。
    4.テストサーバー上で管理画面に入り、UnderConstruction というアクセス禁止をするプラグインで禁止設定した。

    ところが、本番サーバーへ http://honban.com へアクセスするとアクセス禁止状態になっています。
    禁止の設定をしたのは、test.com のテストサーバーであったはずなのに、何故、本番サーバーへのアクセスが禁止になってしまっているのでしょうか。

    本番サーバー、テストサーバーの両方から管理画面には正常にログオンできる状態です。どうなっているのでしょうか。 何かテストサーバー上のの設定がまた足りないのでしょうか。

    この状態だと、外部から見たら2つの本番サーバーがある?と見えてしまうといけないので、とりあえず、テストサーバーのwww/wp フォルダーを全ユーザーから読み取り禁止のプロパティに設定してあります。

    これからテストサーバー上で、WordPressの移行のテストを使用としているのですが、この状態では、テストサーバーだと思って、更新すると、それが本番サーバーに反映されてしまうのではないかと不安です。

    テストサーバーを本番サーバーとは完全に分離するには、どうしたらよいのでしょうか。

    どうぞアドバイスをよろしくお願いいたします。

    tom angle

    (@tom-angle)

    お世話になります。

    追加補足です。
    本番サーバーからDBをエクスポートする際に、下記のオプションを有効にしていませんでしたが、これが問題ということは考えられますでしょうか。

    「DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT を追加」

    どうぞよろしくお願いいたします。

    munyagu

    (@munyagu)

    テストサーバーは、テストサーバー用のデータベースを作成し、そちらを参照するようにwp-config.phpの記述を変更しましたか?
    変更していないと、どちらも本番のデータベースを参照している可能性があります。
    その場合、テストサーバーの管理画面での変更は、本番サーバーにも影響してしまいます。

    tom angle

    (@tom-angle)

    munyaguさん、いつもお世話になります。

    >テストサーバーは、テストサーバー用のデータベースを作成し、そちらを参照するよう
    >にwp-config.phpの記述を変更しましたか?

    はい、切り替え直後は、これを書き換えるのを忘れていました。すぐに気が付いて下記の
    部分をテストサーバー用の内容に書き換えましたが、状況は変わりません。

    —– テストサーバーのwp-config.php ———
    /** WordPress のためのデータベース名 */
    define(‘DB_NAME’, ‘xxxxxxxxx’);

    /** MySQL データベースのユーザー名 */
    define(‘DB_USER’, ‘yyyyyyyyy’);

    /** MySQL データベースのパスワード */
    define(‘DB_PASSWORD’, ‘zzzzzzzzz’);

    /** MySQL のホスト名 */
    define(‘DB_HOST’, ‘wwwwwwwww’);
    —————————————

    気になる点は、管理画面の 設定 -> 一般 の画面で下記のアドレスが本番サーバーの
    アドレスになったままです。

    WordPress アドレス (URL): http://honban.com/wp
    サイトアドレス (URL): http://honbna.com

    これを http://test.com/wp と http://test.com に変更しなればならないのかなあ・・と
    思ったりしたのですが、そもそも、テストサーバーにログオンして今出ているその画面がもしかして
    本番の画面だったら・・・と思い試すことをためらっています。

    どうぞアドバイスをよろしくお願いいたします。

    munyagu

    (@munyagu)

    以下のサイトなどを参考に、テスト環境のデータベースのドメインなどをテスト環境のものに書き換えてください。
    WordPressアドレスやサイトアドレスもこれで書き変わります。

    https://junjun-web.net/tool/search-replace-db-master/

    tom angle

    (@tom-angle)

    munyaguさん、

    私の「やったこと」のところに報告済みですが、wp-config.phpのことについて、searchreplacedb2.phpを使ったテストサーバーのDB内の本番ドメイン名をテストドメイン名に変更した、ことについても報告してあります。

    もう一度報告します。これについて、具体的に何が不足している、あるいは、何が問題と思われるというご指摘なのでしょうか。

    ————-再投稿————

    ●問題: 本番サーバーをテストサーバーに移行しました。テストサーバーでは、正常に管理画面にも入れたようなのですが・・・ この管理画面が本番サーバーなのか、テストサーバーなのか 判別がつかなくて困っています。

    ●やったこと:

    1.本番サーバーからファイル、データベースをテストサーバーに移した。
    ここで、本番を honban.com , テストサーバーを test.com という仮名で以下を説明します。

    2.searchreplacedb2.phpを使ったテストサーバーのDB内の本番ドメイン名をテストドメイン名に変更した。

    3.テストサーバーのwp-config.php をテストサーバーのDB情報に更新した。

    4.テストサーバー上で管理画面に入り、UnderConstruction というアクセス禁止をするプラグインで禁止設定した。

    ところが、本番サーバーへ http://honban.com へアクセスするとアクセス禁止状態になっています。
    禁止の設定をしたのは、test.com のテストサーバーであったはずなのに、何故、本番サーバーへのアクセスが禁止になってしまっているのでしょうか。

    本番サーバー、テストサーバーの両方から管理画面には正常にログオンできる状態です。どうなっているのでしょうか。 何かテストサーバー上のの設定がまた足りないのでしょうか。

    この状態だと、外部から見たら2つの本番サーバーがある?と見えてしまうといけないので、とりあえず、テストサーバーのwww/wp フォルダーを全ユーザーから読み取り禁止のプロパティに設定してあります。

    これからテストサーバー上で、WordPressの移行のテストを使用としているのですが、この状態では、テストサーバーだと思って、更新すると、それが本番サーバーに反映されてしまうのではないかと不安です。

    テストサーバーを本番サーバーとは完全に分離するには、どうしたらよいのでしょうか。

    tom angle

    (@tom-angle)

    munyaguさん 

    いつもお世話になります。

    先のご指摘は、searchreplacedb2.php でのDBのドメインアドレスの書き換えが正しくされてない、のではないか、とのご指摘であったのでしょうか。
    私として、正しく書き換えたつもりですが、それを確認する方法は何かあるのでしょうか。
    できれば、私のミスがないことを確認したいのですが、どうぞよろしくお願いいたします。

15件の返信を表示中 - 1 - 15件目 (全16件中)
  • トピック「WordPressの復元方法について」には新たに返信することはできません。