Проблема архивирования это не проблема. Никаких одинаковых ФС не нужно. Вся аутентичная информация содержится в дополнительном файле, как и положено для архивов. Отличие лишь в том, что это как бы архив, но не архив, ибо без сжатия и без контейнера. Восстановление будет происходить с помощью этой карты. DISM, Wbadmin, recimage, и другие средства архивирования, кроме File History, создают карты автоматически и отлично восстанавливают образы, как с DVD, так и с FAT флешек.
Задержки на монтирование или на каждую команду? А keep-alive там не работает? :)
Боже упаси.
20 лет.
В жизни ни разу не был пьян.
Всегда отказывался на предложение выпить алкоголь. Никаких проблем в общении со знакомыми. Да и знакомые не те. Очень доволен, что "имею иммунитет к этой чуме".
Когда очень плохо, есть желание выпить... кофе. Да впрочем, и когда хорошо. :)
Проводник Windows поддерживает работу с FTP, WebDAV по ярлыку (предварительно ассоциировать проводник с FTP протоколом в панели управления пункт "Программы по умолчанию") или через ручное монтирование диска. Есть расширение для поддержки SFTP.
Поддержка активного режима включается в свойствах Internet Explorer.
Лично я, использую проводник.
Смотрите.
1. Есть документы на компьютеры, которые нужно синхронизировать в облако, по аналогии с Dropbox. То-есть, они будут редактироваться с разных устройств, а облако как-бы посредник.
2. Есть компьютеры, системные файлы которых будут архивироваться в облако по аналогии с Time Capsule.
3. Есть сервер UNIX, который должен архивироваться по аналогии с Time Capsule (все файлы, кроме тех, которые уже есть на компьютере) на главный компьютер, где смонтирован диск через те же средства архивирования, но уже не системного диска, а сетевого.
Итого, получается, что сервер архивируется на компьютер, а компьютер на сервер. Одним слово - синхронизация, зеркало.
У меня стоит вопрос в одном - подходит ли для облачного хранилища WebDAV протокол и как его лучше реализовать.
iamsens, ну так напишите мне недостатки сетевого диска. А то ноль смысла в вашем сообщении, абы написать. 🙅
По SFTP доступ ко всем директориям по-умолчанию для root. Чем же SFTP безопаснее WebDAV? Тем, что запросы не шифрует? :)
Оптимизайка, совсем нет. Сервер будет работать по типу облачного хранилища, и кроме двухстороннего бекапа (с компьютера на сервер, а с сервера на компьютер), будет еще и синхронизация документов.
WebDAV интегрирован в системы Win и Mac OS. С WebDAV можно работать прямо через проводник, впрочем, как с небезопасным FTP. SFTP является не официальным протоколом, поэтому, для работы с ним нужны заплатки. Соответственно, с WebDAV может работать любая встроенная в ОС утилита, которая работает с сетевыми дисками. Я искал, но не нашел путной программы, которая бы добавила возможность работать с SFTP как с сетевым диском. В WebDAV это по умолчанию.
Кроме того, WebDAV является безопаснее за SFTP, он шифрует не только данные, но и команды.
А у нас работает. Приезжайте к нам. На Youtube. :)
Dinozavr, уважаемый, я вам привожу хотя-бы какие-то аргументы. От вас я увидел кучу эгоцентризма, но ноль аргументов в следующей строчке, с которой все и началось.
Вы эту дискуссию начали, вы и приводите аргументы.
[ATTACH]133237[/ATTACH]
Dinozavr, для меня, PDO в проекте - верный признак халтуры.
Все входящие данные у меня проверяет отдельный метод. Я указываю все допустимые $_POST, $_GET, $_COOKIE, их тип, максимальную и минимальную длину или значения (для цифровых значений), надобность в экранировании специальных символов. Данные, которые проходят валидацию попадаю в $_SESSION (memcached), где номер объекта равняется UNIX время запроса.
Таким способом я отлавливаю нужные данные раз и навсегда и работаю с ними в любой части скрипта. Кроме того, я введу учет каждого запроса пользователя. И если случится какая-то ошибка во время выполнения запроса, будь-то, например, ошибка подключения к базе данных, я смогу восстановить все входящие данные.
А что ваш PDO::prepare? Он расходует ресурсы на парсинг текста, и фактически только экранирует специальные символы и валидирует SQL запрос, который у меня в production версии обязательно верный. Я уже молчу о том, что данные $_SESSION у меня сохраняются и после завершения работы скрипта, я могу их использовать многоразово, когда PDO валидирует запрос и данные каждый раз.
Рассмотрим пример. Ожидается FLOAT под $_POST['id'].
Мой метод: (float) $_POST['id'].
PDO: prepare, execute(['id' => (float) $_POST['id']]) (проверка на спец. символы).
Вопрос: зачем инициализировать поиск спец. символов в FLOAT, INT, STRING, которые пользователь не может изменить? Это нужно только в случае входящего STRING, для такого случая, у меня есть тип SQL.
Моя структура гарантирует не только невозможность SQL инъекций, а и валидность каждого входящего параметра. А Database служит только посредником для непосредственно исполнения SQL запросов. В которых ошибок по существу быть не может.
Каждый метод (даже connect) в PDO выполняется медленнее - причины очевидны. Чем сложнее конструкция - тем сложнее и медленнее выполнение. Возможно, PDO кому-то и полезен, например, криворуким новичкам, но в любом серьезном проекте, рано или поздно будет поставлен вопрос об оптимизации производительности - отказе от PDO.
Dinozavr, PDO - жирный монстр. Жирный и неуклюжий. Использовать PDO ради одного языка, то самое, что использовать jQuery ради одной функции.
PHP рекомендует использовать mysqli.
[ATTACH]133235[/ATTACH]
