Серверы резервных копий

[zhudovvv]

Доброго времени суток! Хотелось бы получить совет.

Ситуация такова:
На серверах резервного копирования используется rsynс

С виндовых серверов копирование осуществляется также rsynс. С помощью cifs-utilits (samba) виндовые файловые шары и каталоги пользователей примонтированы в fstab
Вылезло ограничение на длину имени файла
При копировании с ext4 на ext4 пока не проверял(предполагаю ошибка тоже есть)

Ограничения файловых систем:
ext2/ext3/ext4 - 255 байт
zfs - 255 байт
btrfs - 255 байт
ntfs - 255 символов
reiserfs - 4,032 байт /255 символов
Reiser4 - 3,976 байт

Пользователи используют кириллицу и пробелы в названиях файлов, следовательно пути еще меньше
Rsynс пишет "File name too long"


Единственным выходом из ситуации вижу использование reiserfs - 4,032 байт /255 символов.

Вопрос - каким образом осуществляется резервное копирование у Вас? Как решаете данный вопрос?
Спец софт(вопрос ограничения файловых систем тут тоже актуален)?
Копии томов?

Хотелось бы сохранить инкрементное копирование, т.к очень удобно

[andytux]

Единственным выходом из ситуации вижу использование reiserfs - 4,032 байт /255 символов.

Не поздновато? Тут поговаривают: "Файловых систем в Linux убыло".
Пороть надо этих "ляписов-трубецких", чтобы не сочиняли заголовки в три строки.

[Usermaster]

Пороть надо этих "ляписов-трубецких", чтобы не сочиняли заголовки в три строки.

Полностью поддерживаю.
Сделать рассылку что если будут делать документы с такими именами, пусть потом не обижаются что данные утеряны.
Были у меня такие пользователи, делали папочку, в папочке папочка..........., в той ещё и файл с именем фиг знает какой длинны.
Потом начинаешь на новый ПК файлы переносить и даже на винде возникают проблемы с переносом из-за длинны.
Странно кстати, Windows даёт создавать а при переносе всё равно проблемы.
Потом сидишь, мучаешься, переименовываешь и проклинаешь этих "юзверей".

[AnrDaemon]

Там совсем другие ограничения. Читайте документацию внимательнее.

[zhudovvv]

Там совсем другие ограничения. Читайте документацию внимательнее.

Вы о reizerfs?
Пользователь добавил сообщение 25 Февраля 2025, 13:50:50:

Единственным выходом из ситуации вижу использование reiserfs - 4,032 байт /255 символов.

Не поздновато? Тут поговаривают: "Файловых систем в Linux убыло".
Пороть надо этих "ляписов-трубецких", чтобы не сочиняли заголовки в три строки.

Спасибо. Вы уберегли меня от использования "метрвой" фс и лишних сложностей в ближайшем будущем

Буду думать над другими решениями. Пока из мыслей - формировать файл отчета с ошибками rsync и выкладывать его куда-нибудь к руководству. Чтоб пользователей сами "воспитывали".

[ALiEN]

Код: [Выделить]

#!/bin/bash

#Папка с длинными именами
DIR=/path/with/loooooooongfilenames

while read File; do 
  FPath=${File%/*}
  Fname=${File##*/}
  Fnoext=${Fname%.*}
  Fext=${Fname##*.}

#Обрезать имя файла до 160 символов. 
  NewName=${Fnoext::160}
 
  echo mv -v $File $FPath/$NewName.$Fext
done < <(find $DIR -type f)
если результат устраивает - уберите echo

[AnrDaemon]

Вы о reizerfs?

Я о допустимой длине путей. 255 это максимальная длина одного компонента, и то не на всех системах, не на всех ядрах, не на всех CIFS шарах.

У меня на старой работе с Samba3 был такой прикол, после обновления системы на Samba 4 и ядро поновее всё ушло.
Но пользователи с тех пор обучены не страдать фигнёй и давать файлам имена, которые можно прочитать и понять.
Пользователь добавил сообщение 25 Февраля 2025, 15:19:39:ALiEN, скрипт не подойдёт для файлов с "двойными расширениями".
.tar.gz, .fb2.zip…

[ALiEN]

не подойдёт для файлов с "двойными расширениями".

ну делов-то 

Код: [Выделить]

Fext=${Fname#*.}

[zhudovvv]

У меня на старой работе с Samba3 был такой прикол, после обновления системы на Samba 4 и ядро поновее всё ушло.
Но пользователи с тех пор обучены не страдать фигнёй и давать файлам имена, которые можно прочитать и понять.

У меня ядро 6.1 samba 4. Увы, проблема есть. Вообщем суть я понял - не нужно решать вопросы административного характера при помощи "костылей". Себе дороже выйдет

[Measurer]

Мы с какого-то времени для резервного копирования используем borgbackup.
Данная система резервного копирования сильно всё упростила.
СтоИт уже у нескольких заказчиков. Сильно экономит место на дисках (на самом деле - очень сильно), и тебе не нужно заморачиваться по поводу ротации резервных копий и количества хранимых копий.
Работает через ssh, авторизация по ключам. Т.е. пока не научатся ломать авторизацию по ключам, данный сервер в полной безопасности, даже если выставлен в инет.
В винде бэкапы работают через WSL.
С ограничением по длине пути к файлу пока не сталкивались (тестировали).

Все клиенты прописаны в режиме только добавления данных.
Бэкапный сервер сам раз в неделю проверяет репозитарии, удаляет ненужные данные в соответствии с планом и сжимает хранилища. Потом, шлёт отчёты в телегу.

Всё на тупых башевских скриптах в 70 строк.
Т.е. бэкапные скрипты одинаковые вообще на всех серверах. Разные только файлы конфигов скрипта.
В случае с файловым сервером, где в сутки меняется пара сотен вордовских документов, время бэкапа составляет пару минут отсилы.

Восстанавливать данные тоже довольно легко: монтируешь репозитарий с бэкапами, выбираешь каталог по дате, копируешь нужное, отмонтируешь репозитарий.