Linuxデスクトップでバックアップを取りたい

icicle · 2023 年 5 月 16 日午前 4:40

概要

Linuxデスクトップを普段使いする場合、バックアップをどのように取得すれば良いか教えてください。

前提

ここでいう"普段使い"とは、

ソフトウェアをインストールして使用する
プログラミングする
Webブラウザ等を使用して、Webサイトを閲覧する
お気に入りの画像をローカルに保存する

などを想定しており、すべての用途を一台の1TB SSDで満たしているものとします。
また必要に応じて、HDD、SSDの増設やクラウド環境の利用は容易に行えるものとします。

観点

私が知りたい観点としては、以下の3つです
（これ以外にも気にすべき点があれば、ぜひ補足をお願いします）。

1. 方法

専用のバッチコマンドを書く必要があるのか、AURなどに便利なソフトウェアが存在するのか
（その場合、どのようなソフトなのか）分かりません。

理想は、

ランニングコストがあまり高くない
技術的に高度ではない（≒設定手順が少なく導入が容易である）
特定のLinuxディストリビューションに依存しない

あたりが満たされていることです。

2. 粒度

Linux OSごとか、指定したディレクトリ単位かでアプローチが変わりそうだと考えています。
当然、普段使いの用途によっても変わるものと思います。

理想は、それぞれ適宜使い分けできるようになることかな、と思っています。

3. 頻度

粒度に依るとも思いますが、目安を教えていただきたいです。

__
「私はこうしている、こう思う」といった、簡単なレベルでもまったく問題ありません。
お気軽にご回答をお待ちしております！

ninotchi · 2023 年 5 月 16 日午後 2:48

前提として
何をバックアップしたいのかで方法が変わってくると思います。

１．OS部分のバックアップ
２．ソースコードのバックアップ
３．写真や文書ファイルなどのデータのバックアップ

バックアップの種類については

Ａ．全体バックアップ＋差分 (tar とか dump)
Ｂ．ミラー(rsync)

いずれにしても同じSSDにバックアップするのはSSDが故障した場合に復元できなくなるので
バックアップ先は別のメディアか他の計算機になると思います。

１．OS部分のバックアップ

仕事であれば dump コマンド（上記のＡですね）でバックアップしますが、
OS部分を dump から復元するのは結構大変です。
自分のPCではそこまでやりません。
最悪再インストールです。（回答になっていませんね・・・）

再インストール時に /home にあるデータを誤って消さないよう
/home 以外の OS 部分のファイルシステムは別の SSD にインストールしています。
再インストール時に心配なら /home の SSD を外しておけば良いので。

linux って USB の SSD からでも起動できるので、OSが起動しなくなってもデータを取り出すのは割と容易です。
暗号化していなければですが・・。

２．ソースコードのバックアップ

バックアップするより構成管理ツールを使うべきですね。 git とか。

３．写真や文書ファイルなどのデータのバックアップ

そうですね。tar コマンドで tar.gz にまとめておくというのも有りですが、
定期的にコピーするなら rsync （上のＢです）でしょうね。
rsync は追加・変更・削除されたファイルのみ同期するのでコピーが早いです。
同じ計算機内でもネットワークで接続された別の計算機にでもミラーできます。
スクリプト書いて cron から起動すれば任意の時間にミラーできます。
注意点としては削除も同期させるかだと思います。

粒度は元データがどの程度の間隔で更新するかですね。
最悪１週間前に戻せれば良いとか、１日前に戻したいとか。
同期する間隔が１日間隔であれば１日前の状態には戻せます。

どのディストリビューションでも使えるか
dump も tar も rsync も相当古い UNIX 時代から存在するコマンドなので、
どのディストリビューションでも使えると思います。
（dump はファイルシステムが xfs の場合は xfsdump のようです。）

技術的に高度か
dump ・・OSのパーティションを復元する場合には技術的に高度
tar・・・一番簡単（ですが、先日間違ってアーカイブ先に消していけないファイル名を指定し、真っ青になりました・・。）
rsync ・・ちょっと難しい

私のデータで一番失いたくないのは写真データなので、
写真データだけは複数のSSDやSDメモリーカード、HDDに分散保存しています。
写真のデータは Windows マシンの管理ですが・・。

icicle · 2023 年 5 月 17 日午後 12:24

@ninotchi さん

ご回答ありがとうございます！

１．OS部分のバックアップ
再インストール時に /home にあるデータを誤って消さないよう
/home 以外の OS 部分のファイルシステムは別の SSD にインストールしています。

そんなことができるんですね？！？（初耳でビックリ）

この話だけで、

Linuxデスクトップの起動のために /home は必須ではないのか？
どこまで別のディスクにファイルシステムを切り出せるのか？
どうやって切り出すのか？（単純にmvはダメそう。シンボリックリンクでも貼る？）

くらい疑問点が増えてしまうのですが、
そういったことができると分かっただけでも収穫です。ありがとうございます！

２．ソースコードのバックアップ
バックアップするより構成管理ツールを使うべきですね。 git とか。

サーバにアップロードしておけば、事実上クラウドバックアップになりそうですね。

３．写真や文書ファイルなどのデータのバックアップ
tar コマンドで tar.gz にまとめておくというのも有りですが、
定期的にコピーするなら rsync （上のＢです）でしょうね。

rsync、ここまで多方面で名前を聞くと、ド定番中の定番なんですね。

rsync ・・ちょっと難しい

簡単に調べて実行してみた限りでは、オプションを覚えればいけそう？
むしろ、cron のほうがちょっと設定難しそうですね。

dump ・・OSのパーティションを復元する場合には技術的に高度

最悪再インストールです（解決になっていませんね）

ninotchi · 2023 年 5 月 17 日午後 4:07

一般的に使うなら /home は必要ですね。
私は ubuntu系と CentOS 系しか使ったことがないのですが、
Manjaro のインストールをさくっと調べた感じでは
/home を別にする選択肢があるみたいです。
おそらくデフォルトでは / と swap の２パーティション構成でしょうか？
ubuntu も同じだったような・・・。

インストール時に SSD が２つあれば１つは / と swap に使用し
もう一つの SSD に /home を設定します。
（LVMは必要がなければ選択する必要はありません。）
/ と swap の SSD は 128GB もあれば十分かなと思います。
/home はまるまる一つのSSDに。

/home を後から別の SSD にする事もできます。
参考に大まかな流れは以下のとおりです。
SDDを増設しパーティションを作成し、ファイルシステムを作成
/mnt などにとりあえず mount し、/home の内容を tar を使ってコピーします。
（ファイルの属性やタイムスタンプを保持する為 tar を使います。）
/etc/fstab を書き換え、新しく作った ssd のファイルシステムを /home をマウントするよう設定します。
今ある /home は /home2 とかに mv し、mkdir /home で空のディレクトリを作ります。
あとは再起動。
間違えるとログインできなくなります・・・。
でも最悪 linux をインストールしたUSB-SSDから起動できるようにしておけば修復できます。

大丈夫です。
私はいつも Google 先生に頼っています！

harukamy · 2023 年 5 月 23 日午前 11:38

Linuxデスクトップの起動のために /home は必須ではないのか？

場合によりますが、必須ではありません。

どこまで別のディスクにファイルシステムを切り出せるのか？

Systemd mountがマウントするのに必要なものが/にあればあとは好きにして良いです。
ただし、ボリュームを細かく分けるのは時代遅れです。

どうやって切り出すのか？（単純にmvはダメそう。シンボリックリンクでも貼る？）

mvで構いません。
fstabに書くだけです。
ただし、failできないものはマウントできなければ起動できなくなります。

なお、ほとんどの場合デスクトップ用途でルートファイルシステムのバックアップは不要です。
/homeは残す必要がありますが、再インストールするほうが単純に時間的に速いです。

前提として、バックアップは必ずupとdownを意識する必要があります。
つまり、バックアップされる側がバックアップする側以外から変更されてはいけません。
そして、tarはやめましょう。ごく一部が破損しただけで全体が展開できなくなります。

そもそも今はディスクのサイズが大きくなっていて、ファイルサイズも大きくなってきているので、アーカイブなどは使わずライブなファイルシステム上にファイルツリーを生成するのが最も汎用的な良いアプローチです。

rsyncは難しくありません。ほとんどの場合 rsync -av $SOURCE/ $DEST/ で事足ります。
ファイルの削除に追従させたい場合は --delete, ファイルは更新されることはない(追加されていくだけ)なら --ignore-existing をつければ良いです。
大きなファイルなどで転送時間が長い場合は --progress を、全体転送量が多い場合は --info=progress2 をつけても良いでしょう。
間違ってもWindowsファイルシステムをDESTに使ってはいけません。多くの場合、問題が生じます。

巨大なストレージなどを対象にするのであれば、Btrfsにして、snapshotを転送するのが一番良いです。
そうすれば差分転送においてリネームにも追従できます。
rsyncではリネームに追従できないため、このような挙動を欲すると自分で書く必要があります。
(私のNasUtilsにそういうリネーマーがあります)
バックアップ先はファイルにできるためBtrfsである必要はありません。ただ、差分で送っていくとファ類の場合は古いものから消していくことができないため、バックアップ先もBtrfsにして展開するほうが扱いは楽です。

あと、cronじゃなくSystemd Timerを使いましょう

harukamy · 2023 年 5 月 23 日午前 11:40

おそらくデフォルトでは / と swap の２パーティション構成でしょうか？
ubuntu も同じだったような・・・。

Manjaroはデフォルトでは単一のパーティションに入れます。
Btrfsにした場合は/, /home, /var/cache, /var/log をサブボリュームに分けます。
swapはオプションです。LUKSオプションを有効にした場合はESPの/boot/efiも切ります。

ninotchi · 2023 年 5 月 24 日午後 1:22

ubuntu も 19.10 あたりだったか swap パーティションは作らなくなり UEFI ブートにすると /boot/efi と / の２パーティション構成になりました。

Systemd Timer ですね。うーん、使う機会が無かったのですが、何かの機会に使ってみようかな。

mv ですが、わたし的にはパーティションを跨いで大量にファイルを移動する場合にはあまりお勧めはしません。
パーティション跨いだ場合 mv は cp して rm するのと同じなので、元のファイルが消されてしまいます。
コピーが成功したのを確認してから元ファイルを削除した方が安全かなぁと。

tar で間違えて元ファイルを上書きしてしまう人が言っても、説得力無いのですが・・・。

harukamy · 2023 年 5 月 24 日午後 6:08

mvは一応、destに完全に書き込んでから消すことに なっています。

まぁ、destにちゃんと書けてないのにmvが消しおったことは1度や2度じゃないですけどね……
mvはバッファリングするので、ATAエラーになったり、readonlyに落ちたりしてdestが書けなくなると、バッファに入った分で書き込み完了としてファイル消しおるので……