Сколько должно быть свободного места для бэкапа?

ИМО: объем данных (сколько будет временных файлов в момент создания архива) + размер получаемого архива - минимум.

А мы откуда знаем сколько?

сайт весит 7 гб с копейками, ну и сам сервер 3 гб итого 11 гб

Уверены что все это нужно постоянно бэкапить? Сервер ставится из пакетов, а конфигурация будет весить всего ничего. Код (движок) сайта должен лежать где-нибудь в vcs (ну вообще зависит от того как разрабатываете, но в любом случае отдельно от контента). Сам контент можно бэкапить инкрементально.

Если vps'ка на DO то можно делать снапшоты ВМки (только на сколько помню это с даунтаймом проходит), стоимость их хранения копеечная.

Хранить бэкапы на той же машине с которой ты их делаешь в принципе так себе идея. Конечно лучше чем их вообще не делать, но я бы взял какой-нибудь storage box у хетцнера, допустим, и хранил бы их там.

Хранить бэкапы на той же машине с которой ты их делаешь в принципе так себе идея.

-Не я их выкачиваю.

Конечно лучше чем их вообще не делать, но я бы взял какой-нибудь storage box у хетцнера, допустим, и хранил бы их там.

-почему бы не на яндекс диск? бесплатный вариант.

Сам контент можно бэкапить инкрементально.

-Согласен с вами! Вот мне и нужно какой-то скрипт настроить, чтобы скажем он выкачивал на яндекс диск не все, а частично.

https://linux.die.net/man/8/backup-manager

Вот как пример, уже готовое:
https://habr.com/post/67111/

достаточно передать ему в качестве параметров логин, пароль и путь к файлу

только статья 2009 года

Копировать данные в другое место на той же машине - это не резервное копирование, а по сути просто копирование данных. От сбоя ФС или умышленных деструктивных действий с ней вас эта копия не спасёт.

Если не хотите разоряться на внешний storage - хотя бы копируйте эти 8гб куда-то на свой компьютер. Если что с сервером случится вы будете очень рады, что данные сохранены не на проблемной машине.

Правило «не храните все яйца в одной корзине» - первое и ключевое при бекапах.

Так это вам надо решить что именно выкачивать, откуда кто-то другой знает особенности вашего проекта. Если используется какой-то готовый движок то можно искать решения для него, но если это что-то самописное - тут только вы сможете это разрулить. На самом деле вариантов решения куча - созданный руками список файлов, анализ предыдущей копии, средства слежения за файлами на диске, да хоть etckeeper на каталог проекта. Но в любом случае определить что бэкапить - ваша задача.

что то типа

ssh .. «tar ..» > backup.tar.bz2

backup.tar.bz2 сразу в папку яндогуглодиска и запустить синхронизацию

вместо команды можно какой то скрипт запустить

ps. можно еще авторизацию ssh только по ключу сделать

ninjabackup, а там уже выберешь rdiff-backup, duplicity, tar или чтонибудь другое. На яндекс диске раньше в условиях использования было запрещено использовать под бэкапы.

backupninja только.

Вообще да, неплохая штука. barberry ты упоролся штоле?

ssh .. «tar ..» > backup.tar.bz2

Лучше тогда уже Rsync, он умеет в инкрементальщину из коробки.

Делай полный бакап и затем инкрементальные (по-крайней мере я именно так делал). Храни 2 полных и сколько надо инкрементальных. tar лучше делать не на файловую систему, а сразу по ssh забирать архив, чтобы с файловой системы шло только чтение (+запись информации для инкрементального бакапа). Бакапы при таких объемах можешь хранить хоть у себя на ноуте, все равно из без тебя никто не восстановит. Базу бакапить лучше отдельно инструментами для бакапа базы. Таким образом у тебя будет два бакапа: файловой системы и базы. Для ФС полезно настроить exclude для файлов ОС, логов, потому как если сломается OS, то скорее всего ты ее переустановишь.

http://www.gnu.org/software/tar/manual/html_node/Incremental-Dumps.html

Такой вот автоматический бакап с ручным восстановлением.

Лучше тогда уже Rsync, он умеет в инкрементальщину из коробки.

т.е rsync может сделать инкрементальный backup сразу в *.tar.bz2
в папку из которой можно сразу синкать с яндогуглодрайвами? а попутно еще и файлик зашифровать?

ps. мне инкрементальные backup'ы пригождались для ms sql, но то время давно прошло.

Если надо шифрование бекапов, тогда можно в сторону duplicity глянуть.

Касательно тарбола -насколько я знаю, рсинк так не умеет.

гуглодрайвы разве не монтируются как обычный webdav или что-то типа такого? В чём проблема закинуть сразу в директорию для синка с удалённым хранилищем?

Это уже не говоря о том, что хранить бекапы на гуглодрайвах или упасилмм на яндексе так себе затея. Но лучше, чем на этом же хосте, да.

хотелось бы как-то автоматизировать и избавиться от этой рутины

Когда у меня возникла аналогичная проблема - сервер с минимальным тарифом и дисковым пространством - я решил бэкапировать только существенные данные на Google-Drive. Для этого написал на bash-е соответствующие cron-скрипты.

Бэкапируются:
* Список установленных пакетов;
* Настроечные системные директории (из /etc и пр) и отдельные файлы по заданному списку в виде сжатых tar-архивов - чтобы без проблем восстановить конкретную конфигурацию сервера;
* база данных, ежедневно (данные меняются редко);
* Директории с веб-приложениями (php, html и пр.) - тоже в виде сжатых tar-архивов;
* Картинки - инкрементальный бэкап, поскольку они занимают существенное место.

В локальной директории Google-Drive и непосредственно на Google-Drive хранятся несколько последних версий указанных архивов (количество конфигурируется в скриптах). При формировании каждого архива его содержимое сравнивается с предыдущей версией и закатывается на Google-Drive только при реальном изменении. Ну и отдельная логика для картинок. Все архивы, кроме картинок, зашифрованы.

Пришлось, конечно, повозиться с написанием скриптов. Но зато потом всё пошло на автомате.

Я сейчас смотрю в сторону этой тройки backupninja, duplicati, duplicity и так-же выискиваю какой-нибудь уже готовый скрипт, который заходил бы на сервер по SSH делал дамп базы в каталог /home/admin/web/, а потом бы черер scp выкачивал бы все это. Кстати на много быстрее чем через FTP.

Пробовал запускать несколько виндовских программ (вроде Iperius Backup), у себя через crossover. Время на бэкап ушло одиннадцать с лишним часов, да еще с ошибками.

На саму VPS-ку устанавливать какие-то скрипты или программы не хочу(незачем захламлять и загружать боевую машину), у меня дома стационарный компьютер работает круглыми сутками, так что и он может бэкапы делать и скачивать.

Спасибо!