Прямо сейчас у меня есть cron для запуска резервного копирования моего сервера через определенные промежутки времени. Я вручную загружаю этот файл прямо сейчас на свой домашний компьютер. Я просто думал о том, чтобы сделать так, чтобы все мои образы резервных копий хранились в двоичных таблицах в базе данных SQL. Это хорошая идея? Похоже, что это может быть.
Спасибо
Задумайтесь на минуту: какова основная цель создания резервных копий?
Да, вам нужно, чтобы они могли как можно быстрее восстановиться в случае какого-либо неудачного события.
Вот почему вы должны использовать принцип KISS при планировании резервного копирования. Сделайте резервные копии изощренными (чтобы вы могли восстановить их с определенной даты / версии), но не слишком сложными. Используйте какое-нибудь уже доступное программное обеспечение для резервного копирования. Хранение двоичных двоичных объектов в MySQL не кажется для меня безошибочным решением. Я хотел бы хранить файлы как файлы, а базы данных как базы данных.
Я понимаю, что на этот раз вы планируете передавать данные от интернет-провайдера к себе домой, но представьте, если сервер MySQL находится в том же центре обработки данных, что и серверы, которые вы хотите сделать резервную копию, и центр обработки данных выходит из строя из-за отключения электричества. Очень важный сервер получает электрический ток из-за отключения электроэнергии и не загружается из-за сбоя жесткого диска. Ваш сервер MySQL загружается, но имеет некоторые повреждения таблицы, которые необходимо исправить, ЕСЛИ это можно исправить. Это сделает процесс восстановления намного медленнее и намного сложнее, чем должно быть.
Кроме того, большая часть создания резервных копий - это на самом деле не фаза резервного копирования, а их регулярное тестирование. Проще увидеть, правильно ли сделано последнее резервное копирование образа, если вы просто откроете свой файловый менеджер и просмотрите изображения, вместо того, чтобы выполнять некоторые операции MySQL SELECT (или использовать какое-либо приложение, которое выбирает большие двоичные объекты из БД).
Но базы данных не совсем бесполезны, когда дело доходит до резервных копий. Программное обеспечение для резервного копирования может использовать его для всех видов метаданных; дата резервного копирования, набор резервных копий, продолжительность резервного копирования, версия файла, контрольная сумма файла и т. д. Такие данные легко хранить и быстро извлекать из БД. Бинарная капля, не так много.
Я не вижу никаких преимуществ хранения изображений в базе данных. Я мог видеть строковую информацию о них в БД, плюс расположение изображений на диске. Это позволит вам искать, например, когда определенные файлы изменились. Причиной для БД является его возможность поиска. Хранение изображений с каплями не позволяет вам их искать, поэтому никакой пользы нет, если только я что-то упустил.
