アカウント名:
パスワード:
何でもかんでもとりあえずバックアップするという安易な姿勢と、フルバックアップからのリストアをしなければ正常動作できないシステム構成(もしあれば)を改めたほうが良いでしょう。
データのうちの大半は実は大して必要のないものだったりすることが往々にしてあります。単純なファイルバックアップの場合、半年以上アクセスのないデータやクローズしたプロジェクトのファイルはバックアップ採取時に後回しにするなどして別枠で保存すればたいていの業務に支障を来たすことはありません。データベースにしても日々積み重なる売り上げデータ等のような場合は月単位で締め作業が発生するため、締めていない今月分のデータを最優先でリストアできるようバックアップを調整しておくと良いです。
もちろん社内全体の合意が必要ではありますが、事実上全てのデータが書き戻されるまで業務が止まるよりはマシでしょうと説明すれば納得して貰えることが多いですよ。言い換えればバックアップ採取時からの保険/リスク分散ですかね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
バックアップそのものについても悩むけど (スコア:2, 興味深い)
戻せるのか、といったことで悩むのは当たり前だけど、 最近は、サービス
止められる制限時間内にバックアップが終わるのか、というのが一番の
悩みですね。
LTOとか高速書き込みしてくれるものを使ってもデータが多すぎて、
バックアップを取りきる前に業務開始時間が来たなんてことが…
Re:バックアップそのものについても悩むけど (スコア:0)
何でもかんでもとりあえずバックアップするという安易な姿勢と、フルバックアップからのリストアをしなければ正常動作できないシステム構成(もしあれば)を改めたほうが良いでしょう。
データのうちの大半は実は大して必要のないものだったりすることが往々にしてあります。単純なファイルバックアップの場合、半年以上アクセスのないデータやクローズしたプロジェクトのファイルはバックアップ採取時に後回しにするなどして別枠で保存すればたいていの業務に支障を来たすことはありません。データベースにしても日々積み重なる売り上げデータ等のような場合は月単位で締め作業が発生するため、締めていない今月分のデータを最優先でリストアできるようバックアップを調整しておくと良いです。
もちろん社内全体の合意が必要ではありますが、事実上全てのデータが書き戻されるまで業務が止まるよりはマシでしょうと説明すれば納得して貰えることが多いですよ。言い換えればバックアップ採取時からの保険/リスク分散ですかね。