[B! バックアップ] orenonihongogayabaiのブックマーク

MySQL8.0.17で導入されたCLONEプラグインについて

はじめに 2019年07月22日にリリースされた MySQL8.0.17 で、新しく「CLONE」機能が実装されました。リリースノート公式リファレンスマニュアル同機能は、これまでのMySQLの運用方法（特にバックアップ）を大きく変える可能性があり、MySQLユーザからの反響も多いです。そこで、本ブログでも様々な観点から同機能について調査してみました。 1. 機能の概要「CLONE」機能を端的に言えば、「既存のMySQLの全データを手軽にコピーする機能」です。ここでいう”全データ”とは、InnoDBのスキーマ、テーブル、テーブルスペース、データディクショナリのメタデータを一式含んだ、物理スナップショットのことを示しています。コピーしたデータはそのままローカルに保存することもできますし、他のサーバに転送すれば全く同じMySQLを複製（クローン）することもできます。 2. 使い方 ※

orenonihongogayabai 2024/03/29

リンク

MySQL Shell でバックアップとリストアをパラレルで実行する

先月リリースされた MySQL Shell 8.0.21 にバックアップのスレッドを並列化させてパラレルで実行する機能と、そのバックアップを同じくパラレルでインポートするユーティリティが追加されました。公式リファレンスは以下になります。 Instance Dump Utility and Schema Dump Utility Dump Loading Utility 上記のリファレンスに記載されていますが、バックアップ及びリストアをパラレルで実行できるだけでなく、バックアップの保存先として、Oracle Cloud の Object Storage を指定できるという画期的な機能も持っています。今回は、上記の機能について簡単に確認してみたいと思います。（MySQL Shellで、1つのテーブルデータファイルをパラレルでインポートする Parallel Table Import Ut

orenonihongogayabai 2024/03/29

リンク

robocopyでフォルダをバックアップ／同期させる－＠IT

robocopyコマンドとは 2つのフォルダの内容を同期させ、ファイルやフォルダの内容を同じ状態に保つ機能は、ファイルサーバのバックアップや個人的なデータのバックアップ、リモートオフィス同士でのデータの同期など、システム管理のさまざまな場面で利用される。このような用途に利用できるコマンドとして、Windows OSにはcopyやxcopyコマンドが標準装備されている。フォルダの同期に利用できる標準装備のツールとしては、この他にも「robocopy.exe」というコマンドラインツールがある。 robocopyは、もともとはリモートのファイルサーバ同士でファイルやフォルダ、ユーザープロファイルデータなどを同期させるために作られたコマンドである。その名前は「Robust File Copy」の略であり、堅固（robust）で確実なファイルコピーという意味を持つ。具体的な機能の例を以下に記す。

orenonihongogayabai 2014/02/11

リンク

find コマンドの -mtime は +1 でも2日前のファイルが対象

Landscape トップページ | < 前の日 2005-07-02 2005-07-06 次の日 2005-07-07 > Landscape - エンジニアのメモ 2005-07-06 find コマンドの -mtime は +1 でも2日前のファイルが対象当サイト内を Google 検索できます * find コマンドの -mtime は +1 でも2日前のファイルが対象この記事の直リンクURL: Permlink | この記事が属するカテゴリ: [unix] [シェルスクリプト] find コマンドの -mtime は +1 でも2日前のファイルが対象となる。つまり、(n + 1) 日前のファイルが対象。n は +0 を指定しても、一日以上前のファイルが対象になる。 - find が古いファイルを検索してくれないとあるテスト用 DB があり、定期的にバックアップを取っている。バ

orenonihongogayabai 2013/11/21

リンク

ファーストサーバの手順の問題点 - きしだのHatena

えらいことなってますが。正規手順と今回の現象の説明などを含めた中間報告が出されています。 http://support.fsv.jp/info/nw20120625_01.html ここで、正規手順で、途中でオペレーションミスがあったときに復旧できない状態になってしまう可能性があることがわかります。具体的には「原因3：メンテナンス仕様」のこの部分。脆弱性対策のメンテナンスに関しては対象サーバー群とそのサーバー群のバックアップ領域に対して同時に更新プログラムを適用するこの時点でこの更新プログラムに不具合があった場合には、リストアできなくなることになるわけです。そして今回はそれがおきたようです。より安全な手順であれば、バックアップ側にパッチをあてている間は正常系がバックアップのバックアップということになるはず*1ですが、どこにもバックアップがない状態になってしまったわけです。手順１

orenonihongogayabai 2012/06/26

リンク

データのバックアップ方法 — Redmine.JP

Redmineに格納されているデータのバックアップ・リカバリ方法です。バックアップ対象 Redmineのデータを保全するためには以下のものをバックアップします。 Redmineインストールディレクトリ以下のfilesディレクトリチケットやWikiに添付されたファイルが格納されています。データベース添付ファイル以外の全ての情報がデータベースに格納されています。 filesディレクトリのバックアップ方法 Redmineのインストールディレクトリ直下のfilesディレクトリ（添付ファイル保存ディレクトリ）をコピーしてください。 filesディレクトリが空の場合、添付ファイル保存ディレクトリが変更されている場合があります。 config/configuration.yml ファイル内の attachments_storage_path の設定を確認してみてください。データベースのバック