Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 52
> то боевую базу 1С
Лично я бы не стал доверять что-то более-менее серьезное Дропбоксу или Я.Диску.
Использую AWS S3/Glacier (разные бакеты для «горячего» и долгосрочного хранения, причем перенос второго на Glacier настроен автоматом через S3 lifecycle) + s3cmd.
Лично я бы не стал доверять что-то более-менее серьезное Дропбоксу или Я.Диску.
Использую AWS S3/Glacier (разные бакеты для «горячего» и долгосрочного хранения, причем перенос второго на Glacier настроен автоматом через S3 lifecycle) + s3cmd.
Из опыта использования Яндекса для бекапа 1С с файловым хранилищем:
Как то в воскресенье позвонил бухгалтер и говорит: я вышла вчера поработать, а сегодня у меня всё то что я вбивало пропало.
ситуация показалась странной для меня, по консультации с 1Сниками, я проверил журнал работы 1С.
В журнале работы значилось, что данные были внесены и не удалялись, но ссылки на объекты базы были значились как Ошибка.
немного поломав голову, я пошел смотреть в папку с базами в ней я обнаружил файлы с названиями:
1Cv8.1CD
1Cv8 (2).1CD
1Cv8 (3).1CD
сначала я не придал значения этому, а потом в папке с другой базой я увидел что в базе лежит только файл 1Cv8.1CD.
таким образом переименовав файл с подходящей датой изменения в 1Cv8.1CD база сразу нормально заработала и все записи появились.
остался только один вопрос после этого: какого черта Яндекс.диск при работе всего с одним сервером, ухитрился получить пять штук конфликтных версий файлов(я предполагаю из-за перебоев связи), и почему даже не сказав мне, он решил что версия которая лежит у него на сервере- главная, а та что у меня на сервере конфликтная — на самом деле эта ситуация очень сильно подпортила ощущения от работы их сервиса.
Как то в воскресенье позвонил бухгалтер и говорит: я вышла вчера поработать, а сегодня у меня всё то что я вбивало пропало.
ситуация показалась странной для меня, по консультации с 1Сниками, я проверил журнал работы 1С.
В журнале работы значилось, что данные были внесены и не удалялись, но ссылки на объекты базы были значились как Ошибка.
немного поломав голову, я пошел смотреть в папку с базами в ней я обнаружил файлы с названиями:
1Cv8.1CD
1Cv8 (2).1CD
1Cv8 (3).1CD
сначала я не придал значения этому, а потом в папке с другой базой я увидел что в базе лежит только файл 1Cv8.1CD.
таким образом переименовав файл с подходящей датой изменения в 1Cv8.1CD база сразу нормально заработала и все записи появились.
остался только один вопрос после этого: какого черта Яндекс.диск при работе всего с одним сервером, ухитрился получить пять штук конфликтных версий файлов(я предполагаю из-за перебоев связи), и почему даже не сказав мне, он решил что версия которая лежит у него на сервере- главная, а та что у меня на сервере конфликтная — на самом деле эта ситуация очень сильно подпортила ощущения от работы их сервиса.
Вообще, живую базу, на которой сейчас работают на включенном сервисе синхронизации лучше не хранить… Бэкап — бэкапом, а когда 1Ска на лету изменяет данные, ЯДиск изменения пробует занести — и создает новые файлы из-за коллизий.
Уж если лежит — ставьте синхронизацию на паузу, пока бухгалтер работает…
У меня такие косяки по молодости с Voyajerом были (portable — TheBat!).
Уж если лежит — ставьте синхронизацию на паузу, пока бухгалтер работает…
У меня такие косяки по молодости с Voyajerом были (portable — TheBat!).
>>Уж если лежит — ставьте синхронизацию на паузу, пока бухгалтер работает…
смешно, получается что я должен сидеть и ждать когда же бухгалтера не будет работать.
>>Бэкап — бэкапом, а когда 1Ска на лету изменяет данные, ЯДиск изменения пробует занести — и создает новые файлы из-за коллизий.
нет здесь никакой коллизии, это кривые руки программиста. Я.диск не должен пытаться что-то изменять пока открыт дескриптор файла на запись, а если уж он все равно выливает базу в состоянии, пока открыт дескриптор на запись, то уж точно, он просто должен непрерывно выливать постоянно файл в инет, и никак не должен мне возвращать файл из своей базы который по определению старее чем мой, потому что мой всё еще в состоянии записи. а они получается передают неправильную метку времени, и тогда их версия оказывается новее моей.
а вообще, наверно для моих целей лучше пользоваться сервисами для бекапа, но просто яндекс подкупил тем что скорость работы очень приличная.
смешно, получается что я должен сидеть и ждать когда же бухгалтера не будет работать.
>>Бэкап — бэкапом, а когда 1Ска на лету изменяет данные, ЯДиск изменения пробует занести — и создает новые файлы из-за коллизий.
нет здесь никакой коллизии, это кривые руки программиста. Я.диск не должен пытаться что-то изменять пока открыт дескриптор файла на запись, а если уж он все равно выливает базу в состоянии, пока открыт дескриптор на запись, то уж точно, он просто должен непрерывно выливать постоянно файл в инет, и никак не должен мне возвращать файл из своей базы который по определению старее чем мой, потому что мой всё еще в состоянии записи. а они получается передают неправильную метку времени, и тогда их версия оказывается новее моей.
а вообще, наверно для моих целей лучше пользоваться сервисами для бекапа, но просто яндекс подкупил тем что скорость работы очень приличная.
Я.диск не должен пытаться что-то изменять пока открыт дескриптор файла на запись
Кажется, это утверждение неверно. Я редактирую документ в ворде, периодически его сохраняя (дескриптор все это время открыт). Внезано приходит медный таз и накрывает мой компьютер. Вопрос: что я испытаю, когда узнаю, что мой файл не сихронизировался с сервером?
Вот о чем и речь.
А еще у меня были такие случаи с Дропбоксом — 1. внезапно пропал файл. вообще пропал, нет ни локально, ни через вебморду. 2. какой-то косяк с версионированием большого файла — актуальной почему-то была самая первая версия, хотя после самой первой заливки я этот файл обновлял пару десятков раз.
Т.е. когда нет полного контроля над этим — нет уверенности в надежности.
А еще у меня были такие случаи с Дропбоксом — 1. внезапно пропал файл. вообще пропал, нет ни локально, ни через вебморду. 2. какой-то косяк с версионированием большого файла — актуальной почему-то была самая первая версия, хотя после самой первой заливки я этот файл обновлял пару десятков раз.
Т.е. когда нет полного контроля над этим — нет уверенности в надежности.
Что такое большой файл?
У меня гигабайтный образ достаточно периодически изменяется и с ним все ок
У меня гигабайтный образ достаточно периодически изменяется и с ним все ок
Образ TrueCrypt-диска на 200 метров.
Аналогично, только 2014Мб
Файл образа каждый раз целиком перезаливается?
Нет.
Сам рабочий образ лежал в другом каталоге, и периодически копировался в каталог дропбокса, перезаписывая лежащее там.
Вроде как заливались какие-то части при синхронизации (т.е. не целиком он туда фигачился).
Через некоторое время похерилась случайно FS. Восстановил систему, и потом данные и тот файл образа из дропбокса (т.е. поставил клиент, и он с сервака вытянул все на диск обратно).
И тут, при монтировании его, обнаружил, что версия то образа самая первая, т.е. там не было вообще никаких изменений. По счастливой случайности, у меня бэкап был тогда построен плюс еще и на оффлайновый USB-диск.
После этого снес файл образа из вебморды дропбокса, перезалил его, и с тех пор апдейты стали проходить нормально (потом контролировал периодически — все ок было).
Сам рабочий образ лежал в другом каталоге, и периодически копировался в каталог дропбокса, перезаписывая лежащее там.
Вроде как заливались какие-то части при синхронизации (т.е. не целиком он туда фигачился).
Через некоторое время похерилась случайно FS. Восстановил систему, и потом данные и тот файл образа из дропбокса (т.е. поставил клиент, и он с сервака вытянул все на диск обратно).
И тут, при монтировании его, обнаружил, что версия то образа самая первая, т.е. там не было вообще никаких изменений. По счастливой случайности, у меня бэкап был тогда построен плюс еще и на оффлайновый USB-диск.
После этого снес файл образа из вебморды дропбокса, перезалил его, и с тех пор апдейты стали проходить нормально (потом контролировал периодически — все ок было).
То есть, так и не понятно в чем глюк был…
Но осадочек, как я уже говорил, остался.
В общем, я сейчас предпочитаю использовать AWS как основной метод бэкапа важных данных (ну и плюс еще оффлайновый бэкап, просто на всякий случай, и зашифрованные копии в дропбоксе и в gdrive по остаточному принципу (ну мало ли, случаи всякие бывают)). Амазону все-же я как-то больше доверяю, и у меня есть больше контроля над процессом.
В общем, я сейчас предпочитаю использовать AWS как основной метод бэкапа важных данных (ну и плюс еще оффлайновый бэкап, просто на всякий случай, и зашифрованные копии в дропбоксе и в gdrive по остаточному принципу (ну мало ли, случаи всякие бывают)). Амазону все-же я как-то больше доверяю, и у меня есть больше контроля над процессом.
У меня такая же беда с бэкапом фоток. Копирую новую порцию фотографий — файлы ещё не докопировались, а Яндекс.Диск уже всё синхронизирует. В итоге файлы переименовываются в file (1).jpg. Единственный способ избежать такой проблемы — выключать синхронизацию, перемещать файлы в папку синхронизации, и после того, как они туда легли и их уже ничто не трогает — включать синхронизацию.
Писал им в техподдержку, ответ был вроде «38000 файлов — это очень много». То есть как баг это не восприняли. Теперь вижу, что не в количестве дело и не я один такой.
Писал им в техподдержку, ответ был вроде «38000 файлов — это очень много». То есть как баг это не восприняли. Теперь вижу, что не в количестве дело и не я один такой.
Спасибо! Как раз подобное решение собирался сделать для своих проектов.
В свое время начал было тоже ставить синхронизацию с DropBox, но идея не прошла, потому что когда бэкап нужен, то его нужно разворачивать «чем быстрее, тем лучше». А скачивать 10Гб неизвестно откуда в ответственный момент (например, когда все полетело) — большой риск. Поэтому приобрели FTP в сети сервера и все сливается туда.
Хотя, базы MySQL полезно иметь в DropBox для быстрого скачивания и восстановления.
Хотя, базы MySQL полезно иметь в DropBox для быстрого скачивания и восстановления.
А зачем что-то скачивать? В тот момент, когда в папку, подключенную к Dropbox, кладется файл, он начинает синхронизироваться со всеми устройствами, подключенными к этой папке. И ничего «скачивать» не нужно, нужно взять файл из папки на сервере.
Я имею ввиду случаи, когда локальная папка не доступна, т.е. в случае полной недоступности системы.
Для простого восстановления данных можно вообще никуда ничего не копировать — складывать просто в архив на сервере :)
Для простого восстановления данных можно вообще никуда ничего не копировать — складывать просто в архив на сервере :)
Локальная папка где? На бэкап-сервере?
Dropbox-аккаунт синхронизируется со всеми компьютерами, к нему подключенными.
Имеется аккаунт, и 10 серверов, которые к нему подключены. Все они кладут свои бэкапы в Dropbox.
На всех серверах будут копии файлов, которые другие положили. А если легли все 10 серверов — то торопиться уже некуда.
Dropbox-аккаунт синхронизируется со всеми компьютерами, к нему подключенными.
Имеется аккаунт, и 10 серверов, которые к нему подключены. Все они кладут свои бэкапы в Dropbox.
На всех серверах будут копии файлов, которые другие положили. А если легли все 10 серверов — то торопиться уже некуда.
В случае 10-ти серверов — все превосходно, я с вами согласен. Хотя прокачивание бекапа в 10Гб на 10 штук серверов download трафика каждый день — небольшой перебор. Но зависит от тарификации, конечно.
У нас просто один сервер, поэтому такой вариант не очень подходит.
У нас просто один сервер, поэтому такой вариант не очень подходит.
Синхронизируйте эту папку с Dropbox-аккаунтом администратора, там есть возможность некоторые папки делать общими для нескольких аккаунтов.
Для 10 серверов можно сделать например 10 аккаунтов, или просто подгружать не все папки.
Для 10 серверов можно сделать например 10 аккаунтов, или просто подгружать не все папки.
Администратор не хочет качать к себе каждый день 10Гб архив.
Кстати, а насколько быстро делается синхронизация? Например отдача 1Гб сколько по времени?
Кстати, а насколько быстро делается синхронизация? Например отдача 1Гб сколько по времени?
Зависит от канала исключительно.
Администратору что — траффика жалко? Ему ничего делать-то не надо, сервер ночью бэкап выгрузил — он ему на машину загрузился к приходу на работу.
Или он компьютер на ночь выключает?
Администратору что — траффика жалко? Ему ничего делать-то не надо, сервер ночью бэкап выгрузил — он ему на машину загрузился к приходу на работу.
Или он компьютер на ночь выключает?
Т.е. сам DropBox скорость заливки никак не ограничивает? Какие объемы бэкапа у вас?
Трафика, конечно, не жалко и до недавнего времени так и делали: сервер делал копию в 3 часа ночи, сервер на рабочем месте чуть попозже подключался по FTP и забирал копию. Вполне, кстати, работоспособная система для 10-ти серверов и без DropBox :)
А когда один раз нужно было закачать архив обратно на сервер, то пару раз были проблемы (канал на отдачу меньше) и приходилось это проделывать несколько раз.
Трафика, конечно, не жалко и до недавнего времени так и делали: сервер делал копию в 3 часа ночи, сервер на рабочем месте чуть попозже подключался по FTP и забирал копию. Вполне, кстати, работоспособная система для 10-ти серверов и без DropBox :)
А когда один раз нужно было закачать архив обратно на сервер, то пару раз были проблемы (канал на отдачу меньше) и приходилось это проделывать несколько раз.
А вообще смысл статьи не в призыве использовать Dropbox, а в призыве делать это безопасно ;)
В клиенте есть опция «Выборочная синхронизация».
Могу посоветовать утилиту Duplicity. Она не только полностью покрывает функционал, описанный в статье, но и избавляет от ненужных телодвижений вроде установки клиента дропбокса.
А зачем ставить dropbox если у него есть api и есть множество готовых скриптов (питон, перл, php, etc)?
А можете объяснить как работает шифрование? А то я не очень понял манипуляции с ключом.
У GnuPG есть 2 ключа: открытый (публичный) и закрытый (приватный). Публичный ключ можно распространять где хочешь и как хочешь, он используется для шифрования данных (файла, письма, т.д.). А приватный надо хранить у себя в строжайшем секрете, он используется для расшифровки данных.
Т.о. автора шифрует публичным ключом бэкапы, а приватный хранит у себя и никому не показывает. Когда понадобится расшифровать бэкап, то автор воспользуется этим приватным ключом.
Или вам что-то другое не понятно?
Т.о. автора шифрует публичным ключом бэкапы, а приватный хранит у себя и никому не показывает. Когда понадобится расшифровать бэкап, то автор воспользуется этим приватным ключом.
Или вам что-то другое не понятно?
Да ну. Надежда на публичные сервисы — дополнительная точка отказа. Ну его, такое счастье.
Для дропбокса можно использовать скрипт dropbox_uploader.sh (если по каким-то причинам не хочется ставить клиент) и в скрипт в конце добавить строку типа:
/path/to/dropbox_uploader.sh -q upload "$FILE" /backu_srv1/
А почему не использовать для этого Bittorent sync? насколько мне известно из описания, может работать и без интернета(проверить это на практике как то не довелось, но функционал то присутствует). ведь можно автоматические копии сливать в папку( чтобы постоянно канал не занимать) и не затрачивая интернет канал пересылать на нужные зоны хранения. Нужно через интернет пробросить — пожалуйста(это если локалки раздельны и не имеют доступа друг ко другу). Во всяком случае можно быть уверенным, что файлы перешлются даже при разрыве соединения, так как P2P. Ну и естественно дополнительное шифрование для безопасности никто не отменял.
Прошу прощения за откровенность, но заметка ни о чем: все это очевидно каждому, кто знаком с bash. Лучше уж написали бы подробно о duplicity, который может шифровать бэкапы при помощи симметричного шифрования gpg или при помощи открытого ключа, поддерживает инкрементальные бэкапы, и может копировать на: локальный диск, ftp, scp, amazon и другие.
Использовал его для копирования шифрованных бэкапов на Amazon, DropBox, флешку и переносной диск.
Более гибкое и удобное решение для зашифрованных бэкапов надо еще поискать.
Использовал его для копирования шифрованных бэкапов на Amazon, DropBox, флешку и переносной диск.
Более гибкое и удобное решение для зашифрованных бэкапов надо еще поискать.
Это не откровенность, а мелкое хамство. «Лучше уж написали бы» — вот и напишите о дуплисити. А автор написал о чем хотел, за что ему спасибо.
Совершенно верно, заметка не о дропбоксе. Это написано во втором абзаце, кстати.
Только тут есть один момент: Дропбокс сейчас есть у каждой домохозяйки. У моего папы есть дропбокс, хотя он на компьютере с 1996 года в Diablo в основном играет. И шансов на то, что увидя знакомое слово, кто-то пойдет и сделает себе наконец скрипт резервного копирования — больше, чем на то, что кто-то начнет себе ставить duplicity.
А польза от tutorial'а, которым никто не воспользовался — сомнительна.
Только тут есть один момент: Дропбокс сейчас есть у каждой домохозяйки. У моего папы есть дропбокс, хотя он на компьютере с 1996 года в Diablo в основном играет. И шансов на то, что увидя знакомое слово, кто-то пойдет и сделает себе наконец скрипт резервного копирования — больше, чем на то, что кто-то начнет себе ставить duplicity.
А польза от tutorial'а, которым никто не воспользовался — сомнительна.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Безопасное резервное копирование с помощью публичных сервисов