ЕТ
Всем привет)
Size: a a a
2021 March 31
LK
А ещё лучше не изобретать велосипед, а использовать средства копирования, автоматически контролирующие целостность файлов, например rsync.
rsync и md5 это не велосипед и не ИЛИ, а И.
Файлы будут жить и после копирования и их нужно контролировать дальше.
Файлы будут жить и после копирования и их нужно контролировать дальше.
t
rsync и md5 это не велосипед и не ИЛИ, а И.
Файлы будут жить и после копирования и их нужно контролировать дальше.
Файлы будут жить и после копирования и их нужно контролировать дальше.
Я, может, чего-то не понимаю, но зачем "контролировать" файлы? Тем более вручную, а не с помощью ФС с поддержкой контрольных сумм. Допустим, есть у вас n файлов с резервными копиями за последние n дней, и рассчитанные md5 к ним. В ходе (очередной?) проверки вы обнаружили, что у одного файла сумма не сходится. И что теперь?
LK
Я, может, чего-то не понимаю, но зачем "контролировать" файлы? Тем более вручную, а не с помощью ФС с поддержкой контрольных сумм. Допустим, есть у вас n файлов с резервными копиями за последние n дней, и рассчитанные md5 к ним. В ходе (очередной?) проверки вы обнаружили, что у одного файла сумма не сходится. И что теперь?
Сценарии могут быть разные, например перемещение файла на другой компьютер при помощи съемного диска и т.п.
Или тем или иным способом через сеть интернет. Не всегда есть возможность и целесообразность использовать rsync
Или тем или иным способом через сеть интернет. Не всегда есть возможность и целесообразность использовать rsync
t
Сценарии могут быть разные, например перемещение файла на другой компьютер при помощи съемного диска и т.п.
Или тем или иным способом через сеть интернет. Не всегда есть возможность и целесообразность использовать rsync
Или тем или иным способом через сеть интернет. Не всегда есть возможность и целесообразность использовать rsync
А при чём тут интернет? rsync проверяет целостность автоматически, независимо от того, куда копируете, хоть в соседний каталог. Вы же говорите о том, что "после копирования" нужно контролировать. Сам факт расхождения контрольных сумм вам никак не поможет постфактум.
LK
А при чём тут интернет? rsync проверяет целостность автоматически, независимо от того, куда копируете, хоть в соседний каталог. Вы же говорите о том, что "после копирования" нужно контролировать. Сам факт расхождения контрольных сумм вам никак не поможет постфактум.
После это не значит "сразу после копирования".
Файлы могут быть перемещены и не один раз.
Файлы могут быть перемещены и не один раз.
СЯ
Я чего-то не понимаю. Но мне обычно не приходится думать о целостности файлов. TCP заботится об это при передачи по сети, а фс недает считать мусор
t
После это не значит "сразу после копирования".
Файлы могут быть перемещены и не один раз.
Файлы могут быть перемещены и не один раз.
Понятно, спасибо, что объяснили.
СЯ
Контрольные суммы нужно хранить отдельно. Это из серии чтобы злоумышленник бэкап не подменил
LK
Сергей Якушев
Контрольные суммы нужно хранить отдельно. Это из серии чтобы злоумышленник бэкап не подменил
Если есть злоумышленники нужно подписывать файлы ЭЦП.
LK
А вообще лучше сразу:
Зашифровать с gpg:
$ gpg --output file.tar.gz.gpg --symmetric --cipher-algo AES256 --passphrase password file.tar.gz
Расшифровать с gpg
$ gpg --output file.tar.gz --passphrase password --decrypt file.tar.gz.gpg
Зашифровать с gpg:
$ gpg --output file.tar.gz.gpg --symmetric --cipher-algo AES256 --passphrase password file.tar.gz
Расшифровать с gpg
$ gpg --output file.tar.gz --passphrase password --decrypt file.tar.gz.gpg
LK
или
$ openssl enc -aes-256-cbc -salt -in /var/lib/postgresql/base-2019-02-13_18-15-11.tar.gz -out /home/user/backup/yandex/base-2019-02-13_18-15-11.tar.gz.enc -k 1234567890
$ openssl enc -aes-256-cbc -d -in /home/user/base-2019-02-13_18-15-11.tar.gz.enc -out /home/user/base-2019-02-13_18-15-11.tar.gz -k 1234567890
$ openssl enc -aes-256-cbc -salt -in /var/lib/postgresql/base-2019-02-13_18-15-11.tar.gz -out /home/user/backup/yandex/base-2019-02-13_18-15-11.tar.gz.enc -k 1234567890
$ openssl enc -aes-256-cbc -d -in /home/user/base-2019-02-13_18-15-11.tar.gz.enc -out /home/user/base-2019-02-13_18-15-11.tar.gz -k 1234567890
Al
Привет!
Al
Почему вэб-сервер может залипать на этапе лого 1с?
I
pg_basebackup: не удалось получить конечную позицию в журнале транзакций с сервера: ??????: ???????????? ???? "core" ??????? ????? ??? ??????? tar
I
Подскажите как в Астра Линукс 1.4 Смоленск решить проблему с кодировкой? используется UTF-8
LK
в 1.6
Настройка локали:
locale -a
C
C.UTF-8
POSIX
ru_RU.utf8
Добавим en_US.UTF-8
sudo dpkg-reconfigure locales
Generating locales (this might take a while)...
en_US.UTF-8... done
ru_RU.UTF-8... done
Generation complete.
locale -a
C
C.UTF-8
en_US.utf8
POSIX
ru_RU.utf8
russian
Настройка локали:
locale -a
C
C.UTF-8
POSIX
ru_RU.utf8
Добавим en_US.UTF-8
sudo dpkg-reconfigure locales
Generating locales (this might take a while)...
en_US.UTF-8... done
ru_RU.UTF-8... done
Generation complete.
locale -a
C
C.UTF-8
en_US.utf8
POSIX
ru_RU.utf8
russian
АШ
Почему вэб-сервер может залипать на этапе лого 1с?
У меня такое было при проблемах с лицензиями
АШ
Но не факт что у вас то же самое, надо читать техжурнал и логи веб сервера