Мені було просто цікаво, як громада створює резервні копії своїх веб-сайтів?
Я беру щоночі скидаю базу даних і переношу її на інший сервер, який потім створюється резервна копія на знімному носії. Він досить автоматизований і, здається, працює, але мені було б цікаво почути, що мають сказати інші.
Відповіді:
Код сайту знаходиться в Subversion, який, у свою чергу, робиться резервним копієм щоночі. Будь-яка розробка коду проводиться на спеціально розроблених серверах розробників. Виробництво оновлюється лише після тестування нової версії.
Вміст у реляційних базах даних резервується щоночі.
Деякі з наших сайтів мають величезний обсяг статичного вмісту (зображення, pdfs тощо), і вони зберігаються на SAN RAID5, дзеркально відображаються в офсетному об'єкті та мають резервні копії на будь-який випадок.
Ми не створюємо резервні копії файлів журналів, оскільки на них не дуже покладаємося.
Один із варіантів, який я використовував на кількох сайтах, - це використання облікових записів SyncBack, JungleDisk та Amazon S3. (Я розміщую посилання на ці продукти та послуги, але SE забороняє нам новим користувачам публікувати більше 1 посилання. Boo.)
Для тих, хто не знайомий з цими інструментами, SyncBack - це дивовижна і дуже насичена функціями програма для синхронізації файлів між різними папками. JungleDisk дозволимо вам створити віртуальний привід, який за лаштунками читає та записує дані в службу зберігання Amazon S3, що є доступним доступним рішенням для зберігання в хмарі (припускаючи, що ви не штовхаєте гігабайт даних у хмару щодня ).
У нас SyncBack працює за розкладом, як-то раз на ніч або раз на тиждень, і він копіює нові / змінені файли з локального жорсткого диска на віртуальний диск JungleDisk і видаляє всі вилучені файли з віртуального диска.
Що ми зберігаємо в хмарі? Що ж, ми маємо SQL Server робити нічну резервну копію, і він налаштований зберігати ці резервні копії протягом двох тижнів. Ці резервні копії щовечора піднімаються до хмари. Ми також щовечора піднімаємо наші сховища вихідного коду. Повне резервне копіювання робиться статичних файлів, активів, утиліт та інших таких файлів щотижня.
Приємно в цьому підході - це те, що всі файли знаходяться у хмарі, тобто ми можемо отримати доступ до них з будь-якого місця. Немає необхідності RDP на спеціалізований сервер, якщо у вас на робочому столі є JungleDisk - ви можете бачити файли в хмарі так, ніби вони були на диску на локальному комп'ютері. Ще одна вигода - це вартість. Для одного з моїх клієнтів компанія, що займається веб-хостингом, яка розміщує цей сайт, продаватиме послуги резервного копіювання на зберігання в інших місцях для своїх відданих клієнтів серверів, але витрати складали кілька сотень доларів на місяць. Цей підхід мав певні передові витрати - ліцензії SyncBack та JungleDisk, а також витрати на зберігання та пропускну спроможність від Amazon S3, але, якщо я правильно пам’ятаю, ці витрати були меншими, ніж коштував би місяць резервного плану хостинг-компанії. І таким чином нам не потрібно приймати хостинг-компанію "
(Мене познайомив із цим підходом колега Майкл Кемпбелл .)
На додаток до Subversion, щомісячних відвалів MySQL та надмірного (дзеркального) зображення сервера, ми зіпсувались тим, що маємо хоста (AISO.NET), який також робить щогодинні знімки як частина всіх своїх хостинг-пакетів. Я не тільки відчуваю себе добре в хостінгу з компанією, яка ніколи не використовувала електромережі (вони живлять весь об'єкт сонячними та вітровими місцями на місці), але і я розумію, що це надійний, простий у відновити знімки І віртуалізоване рішення, яке перезавантажується буквально за мить ока, якщо це коли-небудь необхідно.
Знімок не раз врятував моє бекон .... і це біса набагато швидше, ніж переходити через рухи untar, перебудовувати і молитися, що йде разом з іншими резервними копіями.
Чому ви зберігаєте головну копію коду на веб-сервері? Я не зберігаю на веб-сервері жодного коду чи програми, які я не можу замінити моментально.
Я створюю резервні копії файлів журналів та даних користувачів, використовуючи спеціально написані сценарії.
У мене є інший код, але це не піклується про резервне копіювання публікацій блогу на веб-сайті в прямому ефірі. У мене є спільний обліковий запис торговельного посередника, і насправді немає автоматизованого способу створення резервного копіювання. Я щойно знайшов, siteautobackup.comтому що він говорить, що він може створити резервну копію всього з рівня WHN, але продукт, здається, ще не працює.
ми запускаємо багатосайтну систему Wordpress. наша стратегія - резервне копіювання баз даних кожні 12 годин у віддалений простір, wp-вміст щодня, public_html щотижня (або коли ми робимо основні зміни в ядрі системи, такі як оновлення ядра Wordpress), і щомісячне резервне копіювання всього домашнього каталогу. це добре працює з нашою системою