No.4141, No.4140, No.4139, No.4138, No.4137, No.4136, No.4135［7件］
テスト投稿
テストさせて頂きます。
𝓣𝓮𝓼𝓽 𝕋𝕖𝕤𝕥 𝔗𝔢𝔰𝔱
🇹🇪🇸🇹
TEST
自動バックアップ機能について誤解があるかもしれないので、ちょいと解説しておきます。#🌱豆知識
てがろぐには自動バックアップ機能があり、バックアップ用ディレクトリに日々バックアップファイルが蓄積されていきますが、この仕様は下記の[⭕正]の方です。
バックアップファイルは、1つ1つのファイル内に「過去の全投稿データ」が含まれています。もし過去500日間に渡って投稿してきたなら、その『500日分の全データ』が1ファイルの中に入っていますし、過去1000日間投稿しているなら『1000日分全部のデータ』が入っています。収録数に上限はありません。
1日単位でバックアップ先ファイルが切り替わって蓄積されていく仕組みなので誤解されがちかも知れないのですが、「1ファイルに1日分しか含まれない」わけではありません。
デフォルト設定では30ファイルまで蓄積して超過分は自動削除されますが、それは『過去30回(日)分の改変バージョンを保存している』というだけです。バックアップファイルを複数個維持する仕様なのは、「昔の編集状態に戻したい」と思ったときに戻せるようにしたり、「3日前に消してしまった過去投稿をやっぱり復活させたい」と思ったときにバックアップから復元できるようにするためです。
……というように、どのバックアップファイルにも「最古の投稿」から「バックアップされた時点」までの全投稿が含まれています。
1日単位でバックアップ先ファイルが切り替わる仕組みなのは、もし新規投稿や編集のたびに毎回ファイルを切り替えていく方式だと、1日に30回以上編集した時点で「昨日の時点に戻したい」と思っても無理になってしまうからです。それを防ぐために、1日単位でバックアップ先ファイルを新規生成する仕様になっています。
そのため、1日に何万回再編集しても昨日までのデータは常に残っているわけですから、仮にゲストユーザに悪戯で1万回投稿されたり、過去の投稿を誤って消してしまったりしても、昨日の時点のデータには絶対に戻せるわけです。
自動バックアップファイル数の設定値の上限を366にしていますが（※その「366」という上限値も誤解を招きやすいかもしれませんね^^;）、それは「さすがに過去366バージョンもの履歴（＝1年分の編集履歴）を残していれば充分だろう」と考えてのことであって、投稿データそのものは5年分でも10年分でも1ファイルの中に全部残っています。
もちろん、Web上に置いているバックアップファイル自体をうっかり（ディレクトリごと）消してしまう、というような操作ミスはあり得ますから、適宜ローカルにファイルをダウンロードしておくことをお勧め致します。
畳む
てがろぐには自動バックアップ機能があり、バックアップ用ディレクトリに日々バックアップファイルが蓄積されていきますが、この仕様は下記の[⭕正]の方です。
⭕正： 1ファイルの中に「過去の全投稿データ」が含まれる。
❌誤： 1ファイルの中には1日分の投稿データしか含まれない。
バックアップファイルは、1つ1つのファイル内に「過去の全投稿データ」が含まれています。もし過去500日間に渡って投稿してきたなら、その『500日分の全データ』が1ファイルの中に入っていますし、過去1000日間投稿しているなら『1000日分全部のデータ』が入っています。収録数に上限はありません。
1日単位でバックアップ先ファイルが切り替わって蓄積されていく仕組みなので誤解されがちかも知れないのですが、「1ファイルに1日分しか含まれない」わけではありません。
デフォルト設定では30ファイルまで蓄積して超過分は自動削除されますが、それは『過去30回(日)分の改変バージョンを保存している』というだけです。バックアップファイルを複数個維持する仕様なのは、「昔の編集状態に戻したい」と思ったときに戻せるようにしたり、「3日前に消してしまった過去投稿をやっぱり復活させたい」と思ったときにバックアップから復元できるようにするためです。
- 今日保存されたバックアップの中身 ➡ No.1～最新投稿の直前(または最後の編集の直前状態)
- 昨日保存されたバックアップの中身 ➡ No.1～昨日の最終投稿
- 一昨日保存されたバックアップの中身 ➡ No.1～一昨日の最終投稿
- ： ： ：
……というように、どのバックアップファイルにも「最古の投稿」から「バックアップされた時点」までの全投稿が含まれています。
1日単位でバックアップ先ファイルが切り替わる仕組みなのは、もし新規投稿や編集のたびに毎回ファイルを切り替えていく方式だと、1日に30回以上編集した時点で「昨日の時点に戻したい」と思っても無理になってしまうからです。それを防ぐために、1日単位でバックアップ先ファイルを新規生成する仕様になっています。
そのため、1日に何万回再編集しても昨日までのデータは常に残っているわけですから、仮にゲストユーザに悪戯で1万回投稿されたり、過去の投稿を誤って消してしまったりしても、昨日の時点のデータには絶対に戻せるわけです。
自動バックアップファイル数の設定値の上限を366にしていますが（※その「366」という上限値も誤解を招きやすいかもしれませんね^^;）、それは「さすがに過去366バージョンもの履歴（＝1年分の編集履歴）を残していれば充分だろう」と考えてのことであって、投稿データそのものは5年分でも10年分でも1ファイルの中に全部残っています。
もちろん、Web上に置いているバックアップファイル自体をうっかり（ディレクトリごと）消してしまう、というような操作ミスはあり得ますから、適宜ローカルにファイルをダウンロードしておくことをお勧め致します。
畳む
ロリポップ情報ありがとうございます！ なかなか一筋縄ではいきませんね。^^;
🍘Re:4132◆なるほど litxxx でも何も書き換えなくて大丈夫でしたか。情報をありがとうございます！ 助かります。
🍘Re:4133◆ハイスピードプランの情報もどうもありがとうございます！
収容サーバ番号で解説を分けるのは正確ではなさそうなので、とりあえず「ロリポップ①」・「ロリポップ➋」とだけ分ける形に変えてみました。(^_^;) ①でダメだったら➋を試してくれ、という感じで……。
ただ、次に公開するバージョンからは、（たぶん）どこのサーバでも $howtogetpath の値は書き換えなくて動作するようになるハズ……だと思っているのですけどもね。ちょいとコードを見直しまして。
🍘Re:4132◆なるほど litxxx でも何も書き換えなくて大丈夫でしたか。情報をありがとうございます！ 助かります。
🍘Re:4133◆ハイスピードプランの情報もどうもありがとうございます！
収容サーバ番号で解説を分けるのは正確ではなさそうなので、とりあえず「ロリポップ①」・「ロリポップ➋」とだけ分ける形に変えてみました。(^_^;) ①でダメだったら➋を試してくれ、という感じで……。
ただ、次に公開するバージョンからは、（たぶん）どこのサーバでも $howtogetpath の値は書き換えなくて動作するようになるハズ……だと思っているのですけどもね。ちょいとコードを見直しまして。
