Nextcloudのバックアップ

Nextcloudがとても便利で色々とファイルを置いているので、壊れると困る。
ということで、バックアップを取っておこうと考えた。

ウチではESXiが動いていて、宅内に向けて幾つかのサービスを提供している。

今回、新しくハードディスクを1つ買ってきて、このESXiが動いているホストに接続する。
このディスクにパーティションを2つ作り、1つをNextcloudのメインストレージ、もう1つをバックアップ領域にする。

将来的には、ディスクを2つ用意して安全なバックアップ環境を作りたいが、そうする場合にも手順はほとんど変わらないから、ここで一旦手順を整理しておく。

バックアップの計画

バックアップの種類

増分バックアップと差分バックアップの違いについて教えてくれている。
The BackStore Blog / 【今更聞けない】差分バックアップと増分バックアップの違いとメリット

これを読んだ後だと、Ubuntuコミュニティヘルプの説明がよく分かる。
説明文は以下のようなものだった。

種類	説明文	DeepL先生の翻訳
Full 完全	A full backup backs up all the files in the back up target.	フルバックアップは、バックアップ対象内のすべてのファイルをバックアップします。
Incremental 増分	An incremental backup backs up all the files that have changed since the last backup.	増分バックアップは、前回のバックアップ以降に変更されたすべてのファイルをバックアップします。
Differential 差分	A differential backup backs up all the files that have changed since the last full backup.	差分バックアップは、最後のフルバックアップ以降に変更されたすべてのファイルをバックアップします。

Ubuntu Community Help Wiki / BackupYourSystem

使用するディスク

8TBのハードディスクを購入し、

5TBをNextcloud
3TBをバックアップ(他のサーバーのバックアップを含む)

で使用することを考えている。

本来は、ディスクを2つ買って片方をNextcloud、片方をバックアップにして、ハードディスクの故障にも耐えられるようにするべきところだとは思うのだけれど、新品なら2年程度は問題なく動いてくれるだろうし、2年後くらいに新しいディスクを買って本来の形に持って行くつもりで割り切りとした。

バックアップの計画

圧縮率が50％だったとしても、2回分のバックアップは取れないかもしれないので、以下の計画とした。

完全バックアップを月1回。
増分バックアップを毎日。
完全バックアップの日には、前回の完全バックアップと増分バックアップを全て削除してから、完全バックアップを開始する。

この計画だと、前回の完全バックアップを削除してから、改めて完全バックアップを作るので、バックアップのない空白の期間ができてしまう。
でも、完全バックアップを一時的にも2セット作るとなると、バックアップ領域のサイズが…将来、ディスクを追加して対応することにして、割り切り。

ある日の状態を完全に復元できること、バックアップから必要ファイルを取り出すことができること、この2つができれば、どうにかなる。

操作

ディスクが届いたので、PCに取り付けた。

物理ディスクを表すvmdkを作る

ESXiでディスクを直接マウントしようと考えている。
何か問題が発生したときにディスクを直接操作できるとか、パフォーマンスが良さそうだとか、色々と考えたため。

ここでは、物理ディスクを表すvmdkファイルを作成する。
このvmdkファイルをマウントすれば、物理ディスクを直接操作できる。

やり方はこちらで教えてくれている。
PC好きの備忘録 / 【VMware ESXi】ゲストOSに直接ディスクを扱わせる『Raw Device Mapping』の設定【RDM】
vmware customer connect / ローカルストレージ用 Raw デバイスマッピング (1017530)

vmkfstoolsコマンドを使い、datasotressdにRawDeviceMappingというディレクトリを作り、そこに物理ディスクを表すvmdkファイルを作成する。

ESXiにSSHで接続して、以下のコマンドを実行した。

[root@ESXi:~] mkdir /vmfs/volumes/datastoressd/RawDeviceMapping
[root@ESXi:~] vmkfstools -z /vmfs/devices/disks/t10.ATA_____WDC_WD80EAZZ2D00BKLB0_____________________________WD2DCA31XYSK /vmfs/volumes/datastoressd/RawDeviceMapping/wd8tb.vmdk

[root@ESXi:~] ls -lh /vmfs/volumes/datastoressd/RawDeviceMapping/
total 0
-rw-------    1 root     root        7.3T Aug 18 21:50 wd8tb-rdmp.vmdk
-rw-------    1 root     root         476 Aug 18 21:50 wd8tb.vmdk

datastoressdにRawDeviceMappingディレクトリを作り、そこにwd8tb.vmdkを作成できた。
8TBのwd8tb-rdmp.vmdkが作られているが、マッピングファイルとかポインタファイルとか呼ばれるもので、実際にこの容量が使われているわけではない。

仮想マシンにディスクを追加

作成したvmdkファイルを「既存のハードディスク」として追加する。
追加してみると、通常の仮想ディスクとは違った表記がされた。

項目	ハードディスク 1(既存/仮想ディスク)	ハードディスク 2(今回追加/RawDeviceMapping)
バッキング	[datastoressd] nextcloud/nextcloud.vmdk	[datastoressd] RawDeviceMapping/wd8tb.vmdk
キャパシティ	200 GB	7.28TB
シンプロビジョニング	はい	いいえ
コントローラ	SCSI コントローラ 0:0	SCSI コントローラ 0:1
モード	依存型	独立型、通常
デバイスのUUID	-	vml.0100<省略>5744
互換モード	-	物理

仮想マシンを起動して確認してみる。

$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0    7:0    0  53.3M  1 loop /snap/snapd/19361
loop1    7:1    0  63.4M  1 loop /snap/core20/1974
loop2    7:2    0  63.5M  1 loop /snap/core20/2015
loop3    7:3    0   103M  1 loop /snap/lxd/23541
loop4    7:4    0 111.9M  1 loop /snap/lxd/24322
loop5    7:5    0  53.3M  1 loop /snap/snapd/19457
sda      8:0    0   200G  0 disk
tqsda1   8:1    0     1G  0 part /boot/efi
mqsda2   8:2    0 198.9G  0 part /
sdb      8:16   0   7.3T  0 disk
sr0     11:0    1  1024M  0 rom

$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 7.28 TiB, 8001563222016 bytes, 15628053168 sectors
Disk model: WDC WD80EAZZ-00B
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

ディスクが認識できていて、ディスクのモデルも出ている。

S.M.A.R.T.の情報も取ってみた。

$ sudo apt install smartmontools
$ sudo smartctl -a /dev/sdb
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.15.0-78-generic] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     WDC WD80EAZZ-00BKLB0
Serial Number:    WD-NNNNNNNN
LU WWN Device Id: 5 0014ee 26b239ecd
Firmware Version: 80.00A80
User Capacity:    8,001,563,222,016 bytes [8.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5640 rpm
Form Factor:      3.5 inches
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-3 T13/2161-D revision 5
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Sat Aug 19 07:33:52 2023 JST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

<省略>

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   100   253   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   100   253   021    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       1
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       1
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       1
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       0
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       4
194 Temperature_Celsius     0x0022   107   107   000    Old_age   Always       -       45
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0

<省略>

温度が気になって触ってみたけれども、少しあたたかい感じ。お茶よりはぬるいから107度はない。
Valueは温度を表しているというよりは、メーカーが決めた値の比率で表現されるようだった。
もっと低いに越したことはないが、エアフローがあまり良くないせいか、これより下がらない。

ESXiにSSHで接続して、同じ情報を見てみる。

[root@ESXi:~] esxcli storage core device smart get -d t10.ATA_____WDC_WD80EAZZ2D00BKLB0_____________________________WD2D
CA31XYSK
Parameter                          Value  Threshold  Worst  Raw
---------------------------------  -----  ---------  -----  ---
Health Status                      OK     N/A        N/A    N/A
Write Error Count                  0      0          N/A    0
Read Error Count                   0      51         N/A    0
Power-on Hours                     1      0          N/A    1
Power Cycle Count                  1      0          N/A    1
Reallocated Sector Count           0      140        N/A    0
Drive Temperature                  45     0          N/A    45
Sector Reallocation Event Count    0      0          N/A    0
Pending Sector Reallocation Count  0      0          N/A    0
Uncorrectable Sector Count         0      0          N/A    0

問題なく情報を取得できるようだ。

パーティションの作成

計画通り、5TBと3TBのパーティションを作成する。

GPTのパーティションテーブルを作成。
5TBのパーティションを作成。
残り(3TB)のパーティションを作成。

$ sudo parted /dev/sdb
GNU Parted 3.4
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel gpt
(parted) mkpart vol ext4 1MB 5TB
(parted) mkpart bak ext4 5TB 100%
(parted) p
Model: ATA WDC WD80EAZZ-00B (scsi)
Disk /dev/sdb: 8002GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  5000GB  5000GB               vol
 2      5000GB  8002GB  3002GB  ext4         bak
(parted) q
Information: You may need to update /etc/fstab.

fdiskでも操作の結果を見てみる。

$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 7.28 TiB, 8001563222016 bytes, 15628053168 sectors
Disk model: WDC WD80EAZZ-00B
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: CFAE5CEB-BC47-40DA-B157-AFE8F0F71855

Device          Start         End    Sectors  Size Type
/dev/sdb1        2048  9765625855 9765623808  4.5T Linux filesystem
/dev/sdb2  9765625856 15628052479 5862426624  2.7T Linux filesystem

5TBという表現で操作ができて、隙間もできなかった。
セクターとかを細かく計算しなくても大丈夫だった。

ファイルシステムの作成

作った2つのパーティションにEXT4のファイルシステムを作成する。

$ sudo mkfs.ext4 /dev/sdb1
mke2fs 1.46.5 (30-Dec-2021)
Creating filesystem with 1220702976 4k blocks and 152588288 inodes
Filesystem UUID: c883eccf-da82-4025-b555-19f02f89e061
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848, 512000000, 550731776, 644972544

Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done

$ sudo mkfs.ext4 /dev/sdb2
mke2fs 1.46.5 (30-Dec-2021)
Creating filesystem with 732803328 4k blocks and 183205888 inodes
Filesystem UUID: 47e48f1c-0ec2-40c5-91b4-0b4d0497f577
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848, 512000000, 550731776, 644972544

Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done

出力される情報のうち、UUIDはマウントに使うなーと思ったが、それ以外の情報の意味がほとんど分からない。
サイズが違うけれども同じ情報が表示されているようだし、これはこれでどこかで整理しないと。

マウント

ファイルシステムができたので、マウントするディレクトリを作って、そこにマウントしてみる。

$ sudo mkdir /var/www/nextcloud
$ sudo mkdir /var/backups/bucket

$ sudo mount /dev/sdb1 /var/www/nextcloud/
$ sudo mount /dev/sdb2 /var/backups/bucket/

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           593M  1.8M  591M   1% /run
/dev/sda2       195G   32G  154G  17% /
tmpfs           2.9G     0  2.9G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/sda1       1.1G  6.1M  1.1G   1% /boot/efi
tmpfs           593M  4.0K  593M   1% /run/user/1000
/dev/sdb1       4.6T   28K  4.3T   1% /var/www/nextcloud
/dev/sdb2       2.7T   28K  2.6T   1% /var/backups/bucket

これで行けそうなので、/etc/fstabで起動時にマウントするように設定。

/etc/fstab

/dev/disk/by-uuid/c883eccf-da82-4025-b555-19f02f89e061 /var/www/nextcloud ext4 defaults 0 2
/dev/disk/by-uuid/47e48f1c-0ec2-40c5-91b4-0b4d0497f577 /var/backups/bucket ext4 defaults 0 2

再起動して確かめる。

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           593M  1.4M  591M   1% /run
/dev/sda2       195G   31G  154G  17% /
tmpfs           2.9G     0  2.9G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/sdb1       4.6T   28K  4.3T   1% /var/www/nextcloud
/dev/sdb2       2.7T   28K  2.6T   1% /var/backups/bucket
/dev/sda1       1.1G  6.1M  1.1G   1% /boot/efi
tmpfs           593M  4.0K  593M   1% /run/user/1000

仮想マシンを起動する度にこのディレクトリで使えるようになった。

Nextcloudのデーターコピー

ウチではDockerでNextcloudが動いていて、データーは/var/www/htmlの下に保管されている。

docker-compose.yml

...
    volumes:
      - nextcloud:/var/www/html
...

ボリュームのファイルは直接触ってはいけないので、alpineのイメージを使って、
　volume:/var/www/html → host:/var/www/nextcloud
のコピーをする。

内容が変化しないように、Nextcloudに関わるコンテナを全て停止する。

$ sudo docker compose stop

alpineを起動する際に、以下のマウントをさせて起動する。

volume:nextcloud → alpine:/nextcloud
host:/var/www → alpine:/mnt(/var/wwwの方がわかりやすかったかも)

そして、実行するコマンドで、alpine:/nextcloud を丸ごと alpine:/mnt にコピーすると、結果としてhost:/var/www/nextcloudが丸ごとコピーされる。

$ sudo docker volume ls
DRIVER    VOLUME NAME
...
local     work_nextcloud

$ sudo docker run --rm -v work_nextcloud:/nextcloud -v /var/www:/mnt alpine cp -a /nextcloud /mnt

コピーできたので、Nextcloudの/var/www/htmlのマウント先を、ホストの/var/www/nextcloudに変更する。

docker-compose.yml

...
    volumes:
     #- nextcloud:/var/www/html
      - /var/www/nextcloud:/var/www/html
...

コンテナを起動。

$ sudo docker compose up -d

これで、5TBのパーティションをメインストレージにすることができた。

動作が確認できて、問題がないと分かったら、ボリュームwork_nextcloudは削除してしまう。

$ sudo docker volume rm work_nextcloud

バックアップ

DockerのNextcloudが動いていて、必要な箇所にはVolume指定をしている。

Nextcloudのバックアップ

毎月1日に完全バックアップを取り、毎日増分バックアップ取る計画なので、1日になったらバックアップとsnapを消してしまう。
その後の最初のバックアップは完全バックアップで、次からは増分バックアップにする。

/path/to/script/backup_daily

#!/bin/bash

BK_BASEDIR=/var/backups/bucket
BK_CDIR=$(pwd)
BK_MONTH=$(date +%m)
BK_DATE=$(date +%d)

docker compose -f /path/to/composefile/docker-compose.yml stop

if [ $BK_DATE = "01" ]; then
        rm $BK_BASEDIR/nextcloud.nextcloud.snap
        # delete old file.
fi

cd /var/www
tar -zcf $BK_BASEDIR/nextcloud.nextcloud${BK_MONTH}${BK_DATE}.tgz -g $BK_BASEDIR/nextcloud.nextcloud.snap nextcloud
cd $BK_CDIR

docker run --rm -v work_mariadb:/mariadb -v $BK_BASEDIR:/mnt alpine tar -zcf /mnt/mariadb.tgz -C / mariadb
docker run --rm -v work_elastic:/elastic -v $BK_BASEDIR:/mnt alpine tar -zcf /mnt/elastic.tgz -C / elastic

docker compose -f /path/to/composefile/docker-compose.yml start

※MariaDBやElasticのバックアップは雑だけれども、バージョンをあわせれば復元はできる。

今回は1周期分しか取らないので、# delete old fileのところに、今あるnextcloud.nextcloud*のファイルを全部消すようにした。
2周期とか、3周期とかのバックアップを取るなら、タイムスタンプをみてファイルを消すようなやり方をしてもいいかもしれない。

バックアップからの復元

フルバックアップから順番に復元していけば良いようだ。

増分バックアップをした場合、ある時作られたファイルが、その後に消されたら、どのように取り扱われるの？
と思ったが、--listed-incrementalを指定して展開することで、アーカイブが作成された時点で存在しなかったファイルを削除するようだ。
GNU / 5.2 Using tar to Perform Incremental Dumps

Nextcloudのファイルは、/var/www/html/data/<user id>/files配下に保管されている。
このファイルを復元させたい、というのであれば、そのファイルを見つけ出して取り出せば良いようだ。

取り出したファイルをそのまま登録する手もあるのだろうけれども、管理者がそのユーザーのファイルとして復元するのには、以下のコマンドが使えるようだ。
Nextcloud community / Backup in reasonable time

$ sudo docker exec -itu www-data php occ files:scan --path /var/www/html/data/user_id/files/path/to/file

※path指定は今の環境からの予測で、実際に試せてはいない。

他のサーバーのバックアップ

今まで、他のサーバーのバックアップは、NASに保管していたが、今後はこのサーバーに入れておこうと思う。
バックアップの結果が簡単に見られるよう、Samba共有を使うことにする。

ドメイン参加と共有フォルダの設定

ウチではSamba ad dcが稼働しているので、それに参加する。
ここに手順を書こうかと思ったけれど、かなり長いので割愛。

少し違うことをやったのは、/lost+foundが見えないようにしたくらい。
(アクセス権のないフォルダを見せなくしている)
日本SAMBAユーザー会 / アクセス権のないフォルダ(ファイル)を非表示にしたい

/etc/samba/smb.conf

[global]
hide unreadable = yes

他のサーバーのバックアップファイル転送

他のサーバーもそれぞれバックアップファイルを作っている。
できあがったら、以下のコマンドでマウントする。

$ sudo mount -o username=<user>,password=<password>,domain=<domain name>,vers=3.0 //192.168.nnn.nnn/share /mnt

※Nextcloudのサーバーをドメインに参加させたので、ドメイン指定をしている。

マウントしたら、ファイルをコピー(この場合は/mntにコピー)すればOK。

大容量のバックアップ

700GB程のデーターを一気に登録してみた。

まず、登録に時間が掛かる。
見た感じ、要因はメタ情報の登録に時間が掛かることのように思う。
登録後はとても快適。

しかし、その日の増分バックアップに13時間かかってしまった。

圧縮時に複数コアを使う

要因は、圧縮処理でCPUのコアを1つ使い切っているが、コアの能力の限界で処理が頭打ちになっていることだった。

コアを2つ割り当てているので、これを使ったらどうなるか試してみることにした。
みつきんのメモ / マルチスレッド環境でのtar

# tar -I pigz -cf /var/backups/bucket/test.tgz nextcloud

はじめの数分しかみていないけれど、CPUは倍くらい使われているが常に100％(というか200％？)になることはなかった。
ディスクの読み書きも限界には届いていないようで、NextcloudのWeb画面は快適に動作していた。

これは、このまま適用してしまおう。

ダウンタイムを最小限にする

CPUコアを2つ割り当てて、仮に処理時間が半分になったとしても、フルバックアップする日には8時間、Nextcloudが使えなくなってしまう。
これはちょっと困りそうなので、バックアップの方法を探してみた。
Nextcloud community / Backup in reasonable time

こちらの投稿の中に、ダウンタイムを減らす方法として、以下が紹介されている。

メンテナンスモードにせずにファイルのバックアップを取る。
バックアップを取った後でメンテナンスモードにして、増分バックアップを取り、データーベースのバックアップを取る。

メンテナンスモードにせずにバックアップを取った場合、バックアップ中にファイルを変更・削除された場合、そのバックアップは役に立たないという点のようだった。
Nextcloud community / Backups and Maintenance Mode

家庭内の利用であってアクセス数は少なく、上記のダウンタイムを減らす方法で十分なバックアップが取得できそうだ。

/path/to/script/backup_daily

#!/bin/bash

BK_BASEDIR=/var/backups/bucket
BK_CDIR=$(pwd)
BK_MONTH=$(date +%m)
BK_DATE=$(date +%d)

if [ $BK_DATE = "01" ]; then
        rm $BK_BASEDIR/nextcloud.nextcloud.snap
        # delete old file.
fi

cd /var/www
tar -zcf $BK_BASEDIR/nextcloud.nextcloud${BK_MONTH}${BK_DATE}p1.tgz -g $BK_BASEDIR/nextcloud.nextcloud.snap nextcloud
cd $BK_CDIR

docker compose -f /path/to/composefile/docker-compose.yml stop

cd /var/www
tar -zcf $BK_BASEDIR/nextcloud.nextcloud${BK_MONTH}${BK_DATE}p2.tgz -g $BK_BASEDIR/nextcloud.nextcloud.snap nextcloud
cd $BK_CDIR

docker run --rm -v work_mariadb:/mariadb -v $BK_BASEDIR:/mnt alpine tar -zcf /mnt/mariadb.tgz -C / mariadb
docker run --rm -v work_elastic:/elastic -v $BK_BASEDIR:/mnt alpine tar -zcf /mnt/elastic.tgz -C / elastic

docker compose -f /path/to/composefile/docker-compose.yml start

※大量のバックアップで時間が掛かることを想定して、最初のバックアップではコンテナを止めない。その後、すぐにコンテナを止めて、増分バックアップを取る。

このコードだと、ファイルの更新が全くされない日にも、フェーズ1と2のファイルが作られることになるけれど、大きな変化があると長時間システムが停止することを考えれば、こちらの方がマシ。

多重起動防止

バックアップスクリプトが24時間を超える…ファイルをどんどん放り込んでいくと、いつかそんな日が来るかもしれない。
そうなると、cronがバックアップスクリプトを起動して、多重に動作することになる。
それを防止するために、以下の処理を先頭に入れて、多重起動を防止した。
Qiita / シェルスクリプトで安全簡単な二重起動防止・排他/共有ロックの徹底解説

/path/to/script/backup_daily

#!/bin/bash
[ "${FLOCKER}" != "$0" ] && exec env FLOCKER="$0" flock -en "$0" "$0" "$@" || :
...

※当該記事に書かれていたスクリプトに不安はなかったが、他から見えるところに書くのでこれを。
※便利な定型コードとのこと。

一部の自動バックアップを諦める

良く考えてみると、

撮った写真はPCに入れていて、それがメイン。
Nextcloudへの登録自体がバックアップになっている。
実家から送ってきてくれている写真は、こちらで変更することはない。
稼働終了した旧システムのvmdkとかパーティションイメージは、念のために取ってあるけれど、まず使うことはない。
(とかいいながら、先日Alfrescoを起動してファイルを1つ取り出したばっかりだけれども)

とかとか、バックアップ自体がいらない、あるいは、時々手で取っておけば十分というケースが結構あった。

これらについて、

ファイルを追加するときには、Samba共有で自宅のPCから。
ファイルを参照するときには、Nextcloudでローカルディレクトリを見せる(読み取り専用)。
気が付いたときに手でバックアップを取る。

という運用に変更、自動バックアップを諦めて、日々のバックアップの容量を減らすことにした。

/var/www/        /var/www/
├ html          ├ html
└ nextcloud  → └ strage
                    ├ nextcloud … Nextcloudで使用
                    └ extra     … Samba共有 & Nextcloudでローカルディレクトリを見せる

まず、コンテナを停止。必要領域はVolume指定しているので、downした。

/dev/sdb1を/var/www/nextcloudにマウントしているので、
/var/www/nextcloudディレクトリにnextcloudディレクトリを作り、そこにファイルを全部移動。
さらに、extraディレクトリを作る。

作成したディレクトリは、オーナーをwww-dataにしておく。

$ sudo docker compose down

$ sudo mkdir /var/www/nextcloud/nextcloud
$ cd /var/www/nextcloud
$ sudo mv * nextcloud
$ sudo mv .* nextcloud

$ sudo mkdir /var/www/nextcloud/extra

$ sudo chown www-data:www-data /var/www/strage/{nextcloud,extra}

ボリューム指定を併せて変更しつつ、extraディレクトリを追加。

docker-compose.yml

  nextcloud:
...
    volumes:
      - /var/www/strage/nextcloud:/var/www/html
      - /var/www/strage/extra:/var/www/extra
...

/dev/sdb1をマウントするディレクトリを作る。

$ sudo mkdir /var/www/strage

起動時にマウントするディレクトリを変更。

/etc/fstab

/dev/disk/by-uuid/c883eccf-da82-4025-b555-19f02f89e061 /var/www/strage ext4 defaults 0 2

再起動して、マウントの状態を確かめる。

良さそうだったので、Nextcloudを立ち上げて確認。

$ sudo docker compose up -d

Nextcloudに管理者でログインし、管理者設定/外部ストレージで、ローカルを指定して/var/www/extraを共有。
共有先を設定し、読み取り専用に設定して、設定を保管する。

Sambaで/var/www/strage/extraを共有し、ファイルを置いて、Nextcloudから見られることを確認できればOK。

最後に、バックアップする時のディレクトリを変更しておく。

/path/to/script/backup_daily

...
cd /var/www/strage
tar -zcf $BK_BASEDIR/nextcloud.nextcloud${BK_MONTH}${BK_DATE}.tgz -g $BK_BASEDIR/nextcloud.nextcloud.snap nextcloud
cd $BK_CDIR

これで、必要最低限のバックアップで済ませることができ、フルバックアップも3時間程度でできるようになった。

ゴミ箱で完全削除したはずのファイルが残っている

一部の自動バックアップを諦めたので、ファイルをゴミ箱に入れ、ゴミ箱からも削除した。
これでバックアップ時間が短くなるだろうと思ったら、増分バックアップなのに巨大なバックアップファイルを作っている。

なんでかな？と思ったら、

ゴミ箱に入れると、ファイルが/path/to/data/<user id>/files_trashbin/filesに移動する。
ゴミ箱で完全に削除すると、NextcloudのWeb画面では見られなくなるが、ファイルが残っている。

という動作をしていた。

よくよく考えると、これが原因だった。

管理者アカウントでフォルダを作成し、家族と共有。
そこに、家族アカウントでファイルを追加。その後に、家族アカウントで削除。

管理者アカウントのフォルダの中にあるものなのだから、管理者でゴミ箱から完全に削除すれば消せそうな気がする。

でも、このことに思い至る前に、以下のページを見つけた。
管理者として、特定アカウントのゴミ箱をクリーンアップできる。
Help Nextcloud / Cannot delete trash files permanently, because the trashbin won’t open

$ sudo docker exec -itu www-data nextcloud bash --login

$ php occ trashbin:cleanup -- <user id>

これで、ゴミ箱にあるファイルは完全に消えた。

大量のファイルを削除したときには、管理者アカウントでゴミ箱をきれいにする、という運用にすれば良さそうだ。

さいごに

実際にNextcloudにファイルを預けてみて分かったこと。

ファイルのアップロードにはかなりの時間が掛かる。
- メタ情報を付けたり履歴を作ったり、やることがかなりあるようだ。
- ネットワークの帯域を使い切っていない、サーバー側が忙しい。
ファイルの削除にもかなりの時間が掛かる。
- 実際のディレクトリからゴミ箱への移動は、大量のファイルでもそれなりの時間で操作が完了する。
- ゴミ箱に入ったファイルにメタ情報を付けるのには、相当の時間が掛かる(操作の結果はすぐに表示されないということ)。
ファイルをアップロードした後は、かなり快適にファイルを取り扱うことができる。
取り扱うデーターが増えると、バックアップにそれなりにリソースが必要。
- 圧縮しながらバックアップを作るのでCPUが長時間かなり忙しい。
- ディスクアクセスが長時間かなり忙しくなる。
- ネットワークを経由する場合、長時間かなりの帯域を使う。
ディスクの故障があっても立ち直れるようなバックアップを取ろうと思ったら、割と豪華な装置が必要。
ユーザーは、サーバーとローカルにファイルがどう置かれているのかを理解しておいてもらう必要がある。
- 特に、Explorerと統合した場合、ディスクの領域を空けるために開放することと、ファイルを削除することには違いがあると理解しておいてもらう必要がある。
- 誰かがファイルを置けばファイルは見えるし、誰かがファイルを消せばファイルは見えなくなる。

全て当たり前すぎることだけれども、実感した。
クラウドストレージサービスの運用って、かなり大変なんだなー。

Nextcloudの便利さは、そのちょっとした大変さを覚悟をするのに十分な理由になる。
撮影した写真やビデオが数百GBあったりして、それを家族数人で取り扱うことを考えると、商用サービスだとまぁまぁ費用が掛かるけれど、Nextcloudを自分で動かしているなら、時々ディスクの購入費用が発生するくらいで、かなり費用が抑えられる。

しばらく使ってみて、問題ないようなら、現在運用中の旧型LinkStationを引退させる予定。
SMB2.0に無理矢理対応させ、ディスクを何度か換装して、長らく便利に使わせてもらっていたもので、本当に面白い装置だった。
何よりも、いざとなったらハードディスクを取り出して、Linuxでマウントすればどうにでもなるというのが強みだった。

Nextcloudのように高機能なシステムは、この点がややこしいだろうと思っていたのだが、最新のファイル自体はここにあった。
/var/www/nextcloud/data/<user id>/files/～
これならどうにかなりそうな気がする。

LinkStationの活躍に感謝をしつつ、次の世代に移行して行く。

コメントはこちらからお気軽にどうぞ～投稿に関するご意見・感想・他

sbin より:

2024年2月29日 18:47

久しぶりです。
ほんとバックアップは面倒ですね。
ついつい手を抜いて zfsに rsync して、zfsでsnapshotしてます。
あ、取り出しは、zfssendです。

返信
- rohhie より:
  
  2024年3月1日 07:31
  
  知っている範囲でできることを探して設定しました。
  ZFSは今日まで知らずにいて(^^; この時にはLVMにするかどうかを考えたくらいです。
  LVMには少しトライしたけれど上手く理解ができず、柔軟な運用ができそうもないと諦めました。
  
  容量が大きくなると、ディスクの交換が大変ですよね。
  もう少し先にゆっくりとトライすることになりそうです。
  
  返信

バックアップの計画

バックアップの種類

使用するディスク

バックアップの計画

操作

物理ディスクを表すvmdkを作る

仮想マシンにディスクを追加

パーティションの作成

ファイルシステムの作成

マウント

Nextcloudのデーターコピー

バックアップ

Nextcloudのバックアップ

バックアップからの復元

他のサーバーのバックアップ

ドメイン参加と共有フォルダの設定

他のサーバーのバックアップファイル転送

大容量のバックアップ

圧縮時に複数コアを使う

ダウンタイムを最小限にする

多重起動防止

一部の自動バックアップを諦める

ゴミ箱で完全削除したはずのファイルが残っている

さいごに

コメントはこちらから お気軽にどうぞ ～ 投稿に関するご意見・感想・他

コメントはこちらからお気軽にどうぞ～投稿に関するご意見・感想・他