Какво ново?
От:
Подробно търсене…
SearchEngines.bg

Това е примерно съобщение за гост. Регистрирайте безплатен акаунт днес, за да станете потребител на SearchEngines.bg! След като влезете, ще можете да участвате в този сайт, като добавите свои собствени теми и публикации, както и да се свържете с други членове чрез вашата лична входяща кутия! Благодарим ви!

FTP backup hosting

Колко е обема за архив? Къде се хоства - БГ или не? Къде искаш да е ФТП-то - БГ или не?
Аз ползвам един питон скрипт - наричам го умния тъп скрипт. Архивирам към 50 мб - в 200 файла.
Какво прави:
През определено време проверява папката дето искам да архивирам за промени (sha512 на файловете).
Ако има промени:
архивира tar файловете всички от тях (тъпата му част)
криптира архива с gpg
качва архива на 1 фтп (без (с)фтп(с))
качва архива на 2 облака през вебдав.
Еми това е.
По тоя начин имам архива на 3 места, криптиран. Верно натрупват се мб-ти, но се прави архив само ако нещо е променено. Данните са важни.
Ако имаш интерес кажи да ти дам цена
 
Един разумен и евтин вариант е да ползваш някой стар компютър с голям нов диск от вас или от офиса и да синхронизира през ненатоварено време.
 
eclipze каза:
Един разумен и евтин вариант е да ползваш някой стар компютър с голям нов диск от вас или от офиса и да синхронизира през ненатоварено време.
Увеличете...
Абе, имам една машинка, дето копа биткойни - ще видя на нея дали ще стане... Би трябвало да няма проблем...
 
azsym каза:
Колко е обема за архив? Къде се хоства - БГ или не? Къде искаш да е ФТП-то - БГ или не?
Аз ползвам един питон скрипт - наричам го умния тъп скрипт. Архивирам към 50 мб - в 200 файла.
Увеличете...
Става въпрос за архивиране на цели виртуални сървъри от ВПС - там си има готов скрипт, само трябва да праща някъде данните. Към момента са около 20ГБ един пълен бекъп, но ми трябват поне 2 пълни през седмица и между тях ежедневни инкрементални, така че трябва да е минимум 100ГБ... Ще видя дали ще е добре на собствената машинка. Само трябва да инсталирам ФТП сървър...
 
mobilio каза:
Изглежда ще преоткриете удобствата на нещо което се казва rsync
Увеличете...

Аз друго разбрах. 100 ГБ са много. Ако си хостнат в БГ търси си фтп в БГ. Иначе мъка.
Най-добре си купи един НАС и му ръгни един 500 ГБ диск. Безшумно и винаги онлайн а си има и ФТП.
Ако НАС-а ти е скъп, един raspberrypi с външен юсб хард върши работа.
 
~~Изглежда ще преоткриете удобствата на нещо което се казва rsync

Да ползваш rsync за бекъп е в топ 3 издънки които можеш да направиш:))

rsync има две логики:

1. Изтрива от бекъпа файловете изтрити от сървъра - резултат: човешка или техническа грешка репликирана и върху бекъпа - извод нямаш бекъп
2. Не изтрива от бекъпа файловете - резултат: в зависимост от системата натрупва по-бързо или по-бавно излишни файлове - извод като стигнеш до възстановяване от бекъп става тъжно

rsync и не работи по криптиран канал, трябва да мине през ssh тунел, любим начин за злоупотреба - разбирай ако влезеш в сървъра влизаш и в бекъпа или обратно
 
eclipze каза:
~~Изглежда ще преоткриете удобствата на нещо което се казва rsync

Да ползваш rsync за бекъп е в топ 3 издънки които можеш да направиш:))

rsync има две логики:

1. Изтрива от бекъпа файловете изтрити от сървъра - резултат: човешка или техническа грешка репликирана и върху бекъпа - извод нямаш бекъп
2. Не изтрива от бекъпа файловете - резултат: в зависимост от системата натрупва по-бързо или по-бавно излишни файлове - извод като стигнеш до възстановяване от бекъп става тъжно

rsync и не работи по криптиран канал, трябва да мине през ssh тунел, любим начин за злоупотреба - разбирай ако влезеш в сървъра влизаш и в бекъпа или обратно
Увеличете...

Идеята е със rsync да си го копираш локално и тук да правиш архивиране. По-добрия начин е защото само ще копира обновените файлове, изтритите и т.н. останалото ще остане както-си-е
1 - със моя метод отпада този проблем
2 - това е по-чалнатия проблем и действително ще натрупа

rsync МОЖЕ да се търкаля върху ssh! https://www.digitalocean.com/community/articles/how-to-copy-files-with-rsync-over-ssh ето един от многото примери как се прави. Отделно можеш да си направиш тунел между машините (прав и обратен).
 
Варианта по точка 1 работи само ако си с разумен брой потребители и ги репликираш на бекъп машината, и винаги носиш риска да останеш изненадан от проблеми с правата точно в момента в който тези данни ти трябват спрешно и не можеш да си играеш да анализираш. Обичайното решение което съм виждал 777 на всичко и след това гледай забавление;))

А точно тези туториали имах предвид и да това е shh тунел като любим начин на злоупотреба, впечатляващо е в какви мащаби се ползват папагалската и една такава логика какви количества мрежи компрометира.

Най-просто казано: ако по една или друга причина прочета ключовете по точка 1 от това което си дал за пример. Аз автоматично имам достъп и до другата машина, така че една от основните причини да имаш бекъп "чужда намеса" по този начин се превръща в бедствие:)

Да обясня най-кратко идиотията на този тип логика, както казах доста разпространена:
1. Имаш бекъп сървър - често не доста обгрижван от ъпдейти и тн.
2. Имаш продъкшън сървъри - цялата ценна информация от тях отива на бекъпа
3. На бекъп машината имаш ключове с които достъпваш всички продъкшън сървъри
4. Намира се някой със свободно време и интерес да достъпи бекъп машината
5. От нея достъпва всички продъкшън сървъри
6. Ако не сте гении по отношение на unix права и потребители и следвате тези турориали, този някой затрива файловете от бекъпа и от сървърите
7. Събуждате се сутринта и деня ви изглежда коренно различно;)
 
Затова аз съм решил проблема по другия начин - пращаш криптиран бекъп по НЕкриптиран канал. Мисля, че е и по-бързо така - до колкото знам криптираните канали за по-бавни като скорост. Може и да греша, но това не променя нищо.
На прод сървъра верно товариш процесора да сметне това-онова, но се предполага, че това е мощен сървър.
Обаче имайки криптирания бекъп, може да се съхранява на безплатни облаци (там където задължително ти гледат данните).
Проблема тук е по-скоро обема - 20 ГБ си е много.
 
Да и нашите неща са така, дали ще се криптира първо файла или след това канала е съизмеримо като натоварване, така че проблема остава по-голямото количество данни само. Но няма сървър който да е равномерно натоварен през денонощието, така че при разумно планиране не се усеща.

Размера не е толкова страшен, ние обработваме над 150 ГБ дневно, а скоро ще има мултимедия която рязко ще качи до терабайти, тогава просто ще обработваме отделни групи данни на транзакция. А пък ако данните ти са на отделни дискове без проблем можеш от сериен да направиш процеса паралелен. При нас е малко по-различно защото са много машини огледални и просто всяка архивира отделен сегмент от данните само, тогава пък натоварването е под половин час за количеството данни които имаме.
 
@azsum

Проблема е, че тези 20Gb идват много на "безплатните" облаци и те порязват. Можеш да използваш AMZN S3 за целта и ще ти коства около 3-4 долара месечно. Хватката е, че ъплоуда е безплатен. Има си туул s3cmd за целта.
 
mobilio каза:
@azsum

Проблема е, че тези 20Gb идват много на "безплатните" облаци и те порязват. Можеш да използваш AMZN S3 за целта и ще ти коства около 3-4 долара месечно. Хватката е, че ъплоуда е безплатен. Има си туул s3cmd за целта.
Увеличете...

Тулчето е хитро. Да.
Там обаче пише, че целия трафик на АМЗС3 се плаща. И ъплоада. Освен ако не е старо инфо.
Проблема с 20 ГБ не е в размера а в скоростта на ъплоад. В БГ, БГ->БГ е ОК скоростта (2-3 МБ/с).
 
Трябва да си влезнал или регистриран, за да отговориш тук.

Горе