4

運が悪いので、これで数日間過ごしました。

すべてのユーザー、グループ、および共有で Freenas の初期インストールを完了した後、USB が失敗しました。データはすべて問題ありませんでしたが、構成ファイルのバックアップがありませんでした。使用する Freenas のバージョンは FreeNAS-8.3.1-RELEASE-x64 (r13452) です。

USB を交換し、すべてを再設定した後、データ ハード ディスクを再接続し、すべてのユーザーとグループの再作成に取り掛かりました。外付け USB ハードディスクへのデータのローカル コピーに使用した Rsync バックアップ スクリプトをセットアップするまでは、すべて問題ありませんでした。

私が使用しているスクリプトは

#!/bin/sh

# Simple script to backup data from BACKUP_SRC to BACKUP_DST
#
# this can be any drive attached to your FreeNAS box ...
# ... internal drive(s), external USB drive(s), external SATA drives(s)

# Backup source
BACKUP_SRC=/mnt/DATA/test/

# Backup destination -- DO NOT include the trailing slash
BACKUP_DST=/mnt/BACKUP1/SHARED

# For a seven day cyclical backup, remove the comment from the line 'DAY=option$
# set the preferred directory name format 'Monday, etc or Mon, etc'
# A = long day name   (i.e. Monday, Tuesday, ... Sunday)
# a = short day name  (i.e. Mon, Tue, ... Sun)
# This will create a daily backup directory (i.e. backup/Sat backup/Sun)
 DAY=/`date +%a`
#
 rsync -aqv -HAX --delete $BACKUP_SRC $BACKUP_DST$DAY

# In the event of a drive failure:
#
#   1. Replace failed hardware.
#   2. Recreate datasets and set appropriate permission
#   3. Reverse paths in this script and re-run it

# end

スクリプトはで実行可能です

chmod +x

ただし、スクリプトは次のメッセージで失敗します

rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1053) [sender=3.0.9]

/var/log/messages にログ エントリがありません

すべてを最初から再作成する前に - ポインタをいただければ幸いです

ありがとう、

4

5 に答える 5

1

私はちょうどこの問題に遭遇します。ソース ディレクトリには、グループに s ビットが設定されていました。

drwxrwsrwx 9 franz franz  4096 Okt 20  2015 Documentation/

これが解決策です。フォルダーとサブフォルダーのグループのビットを削除します。

$ sudo chmod -R  g-s Classes/  Configuration/ Documentation/  Resources/

これで rsync はエラーなしで実行されます:

rsync -av /var/www/html/typo3conf/ext/static_info_tables_it /run/media/franz/SICHER1/backup/typo3
于 2016-08-27T19:28:24.883 に答える
1

user2640725 と Joseph の両方に、あなたの提案に対するフィードバックがなかったことをお詫び申し上げます。また、私の質問に時間を割いて回答してくださったことに感謝します。デフォルトとして、質問への回答が通知されると思っていました-それ以来、設定でこれを変更しました

問題は「A」オプションにあったようです

rsync -aqv -HAX --delete $BACKUP_SRC $BACKUP_DST$DAY

Rsyncのマニュアルページによると

-A、--acls は ACL を保持します (-p を意味します)

これが削除されるとすぐに、エラーはなくなりました。奇妙なことに、これをテストしている間、ソース フォルダーと宛先フォルダーが同じファイル システムにあるため、これが問題を引き起こしている理由がわかりません。

このオプションを削除すると奇妙な副作用があるかどうかを確認するためにもう少しテストしますが、当面は、ACL 属性が引き継がれないことを犠牲にして、少なくともデータのコピーを保持することを好みます。

于 2014-05-31T12:18:09.310 に答える
0

たまたま同じエラー コードが表示され、ホスティング プロバイダーがサーバーを移行したためにソース ディレクトリが変更されていることがわかりました。$BACKUP_SRC のパスが存在するかどうかを確認します。

于 2013-09-20T21:17:47.157 に答える
0

webapp のアセットを azure にアップロードしているときにこのエラーが発生しました。理由は、古いリソースが使用されていたため、上書きできなかったためです。サーバーを停止してから上書きする必要がありました。

于 2020-07-16T11:26:39.833 に答える
0

rsync の -q パラメータなしで詳細情報を見つけることができ、rsync のエラー コードはhttp://www.admon.org/faqs/how-to-understand-error-code-of-rsync/で見つけることができます。 rsync のマニュアルページ。幸運を！

于 2014-03-03T07:54:10.847 に答える