Обсуждение — Зашифрованные бэкапы на VPS: restic и borg на практике

Статью прочитал, схема рабочая, но она целиком про linux. У меня половина хозяйства — win server: 1С и mssql. Там ломается уже на первом шаге, и в тексте про это ни слова.

restic на винде без --use-fs-snapshot открытые файлы снимает как есть. mdf и ldf в этот момент держит сервер, на выходе каша. Бэкап при этом зелёный, restore «успешный», а база не встаёт. Узнают об этом обычно в тот день, когда восстанавливаются.

Как делаю я:

restic -r <repo> backup C:\data --use-fs-snapshot

Служба Volume Shadow Copy должна быть Running, не Disabled, иначе флаг молча ничего не даст.

Живой mdf я всё равно не таскаю. Сначала штатный bak средствами sql, restic забирает уже готовый файл. С 1С так же.

borg под винду не ставил и не собираюсь, там своя история с wsl.

Вопрос к тем, у кого win server в хозяйстве: вы --use-fs-snapshot используете или сначала дампите штатно? И главное — restore на чистой машине проверяли, или ориентируетесь на то, что restic не выдал ошибок?

lexa92 да. без --use-fs-snapshot restic на win server открытые базы снимет кашей. restore потом «успешный», sql не встаёт. данная ошибка типичная, в линуксовых гайдах её просто нет.

по делу:

• служба Volume Shadow Copy — Running, не Disabled
  
• restic backup с --use-fs-snapshot. без флага vss даже не дёрнется
  
• живой mdf я так не таскаю. sql — сначала штатный bak, restic уже файл. с 1с то же самое
  

borg под винду не ставил и ставить не буду. restic хотя бы снапшот умеет.

какая база и какая версия restic. без этого дальше советовать бесполезно.

pavel_63 снапшот ок. 3389 в wan restic не спасёт. ключ репы рядом не клади.

pavel_63 mssql 2019 standard, 1С файловая плюс sql, win server 2019. restic 0.16.4, бинарник с github, не scoop и не wsl.

--use-fs-snapshot в логе пишет, что vss-снимок взял. Volume Shadow Copy — Running, это уже было в первом посте. живой mdf в репу не кладу: сначала штатный bak, restic забирает уже файл. снапшот оставляю на логи и конфиги, которые sql сам не дампит.

restore на чистую машину гонял. один раз restic check был зелёный, а база из снимка файлов не встала — встала только из bak. зелёный check ничего не значит, кружок у restic тоже всегда зелёный.

n1kita писал:
3389 в wan restic не спасёт

restic и не должен. rdp в мир не торчит, ключ репы рядом с репой не лежит. это другой разговор.

какая у тебя версия restic и что за sql, если дальше советовать собрался? скинь вывод, без него гадать не буду. а у кого check зелёный, а restore нет — тоже ловили?

n1kita вы правильно сказали, и я тут не спорю. restic репу хоть трижды шифруйте — если 3389 торчит в wan, бэкап уже ни при чём. Видел не раз: человек настроил restic, check зелёный, а rdp с улицы открыт «на время, пока чиню». Сессию снимут раньше, чем forget отработает. Порт в интернет НЕ ОТКРЫВАЙТЕ. У меня win server слушает 3389 только локально, заход через туннель с Keenetic. restic отвечает за пожар и диск, а не за то, чтобы с улицы не зашли.

Ключ репы рядом с репой тоже не держу. Пароль restic в менеджере на другой машине, не в каталоге репозитория и не в bat-нике рядом с задачей Планировщика. Иначе шифрование репы — самообман: взяли диск, взяли пароль, дальше как без шифра.

lexa92 по версиям отвечаю, раз спросили. Win server 2016 standard, mssql 2017 standard, 1С и файловая, и sql. restic 0.16.4, бинарник с github, не scoop и не wsl. Служба как задача Планировщика от SYSTEM. Volume Shadow Copy — Running, это давно, без этого флаг молча ничего не даст.

lexa92 писал:
один раз restic check был зелёный, а база из снимка файлов не встала — встала только из bak

так это и устроено, и check тут ни при чём. restic check проверяет, что блобы в репе на месте и хеши сошлись. Он не проверяет, что sql этот mdf примет. Зелёный check я ловил тоже. На восстановлении файловый снимок базы не поднялся. Поднялся штатный bak. После этого живой mdf в репу не кладу, даже с --use-fs-snapshot. Снапшот тома sql в этот момент мог не сбросить страницы на диск. VSS restic-у даёт согласованный том для логов и конфигов, не для живой базы.

по шагам, как у меня в самаре:

• sql: сначала штатный backup database в bak, с verify. Каталог локальный, не сетевой диск и не та же репа restic. Иначе «бэкап бэкапа» путается в голове, а при restore непонятно, какой файл свежий.
  
• 1С файловая — выгон пользователей, dt или копия каталога базы. Живую 1cv8.1CD restic-ом не снимаю. Потом restore «успешный», а конфигуратор базу не открывает. Узнают в тот день, когда надо открыть.
  
• restic backup этого каталога плюс конфигов. Для конфигов и логов — --use-fs-snapshot. Без флага vss даже не дёрнется.
  
• репа на vps, restic шифрует сам. Пароль не в том же месте, что репа, и не в том же месте, что исходные bak.
  
• forget и prune по расписанию, отдельно от backup. В одной команде у меня один раз prune пошёл, пока backup ещё писал — репа на полчаса встала, задача по красному. Теперь сначала backup, через час prune.
  
• restore. Check зелёный не считается. Раз в квартал поднимаю bak на запасной машине, sql стартую, 1с подключаюсь. Без этого бэкапа нет, есть зелёный кружок.
  

borg под винду не ставил и ставить не буду. wsl ради бэкапа win server мне не нужен, данная история не моя. restic хотя бы vss умеет из коробки.

ещё грабли, которые ловил сам, чтобы потом не искать:

• Планировщик от пользователя с сессией. Задача молча не стартанула после перезагрузки сервера. От SYSTEM, права на каталог bak выданы отдельно. Иначе в логе пусто, restic «как бы работал».
  
• Антивирус на лету кусал restic cache. Исключение на cache и на restic.exe. Без этого backup «успешный» за три секунды, в репе пусто, check при этом зелёный — та ещё шутка.
  
• Часовой пояс. Планировщик win server и utc. У меня самара utc+4, задача «в три ночи» один раз уехала на утро, sql в это время уже работал, bak снялся на живую нагрузку. Сейчас смотрю локальное время сервера, не то, что в кабинете нарисовано.
  

n1kita 3389 и restic — два разных контура. Один про то, чтобы в систему не зашли. Второй про то, чтобы после диска поднять базу. Путать их не стоит: restic порт не закроет, закрытый порт базу после пожара не вернёт. Оба нужны, по отдельности.

Я раньше сам ориентировался на check. Потом поймал ту же кашу, что lexa92: репа целая, база из файлов не встаёт, из bak встаёт. С тех пор без пробного restore на чистую считаю, что бэкапа нет. Зелёный кружок restic — как светофор на пустой дороге: горит, ехать всё равно некуда.

а у кого-то check зелёный, а база из файлового снимка не встала — ловили, кроме этого случая? И restore на чистую гоняете раз в квартал или «ну restic же не ругнулся»?

pavel_63 писал:
данная схема как раз так и работает, и check тут ни при чём

check репу смотрит, sql — свой restore. это не одно и то же. у меня check был зелёный на каше из mdf, встала только из bak. на 2016 vss живую базу тоже не вылечит.

планировщик от SYSTEM нормально. пароль не в bat рядом с задачей.

restore bak на чистую 2016 гонял или только check?

lexa92 да. check для sql не замена.

lexa92 писал:
restore bak на чистую 2016 гонял или только check?

гонял. не на той же машине — на запасной win server 2016 в кабинете. штатный restore bak, sql 2017 поднялся, 1С к базе цеплялась. файловую 1С отдельно копировал и открывал. без этого «успешный бэкап» для меня ничего не значит.

vss на 2016 живую базу не вылечит, тут не спорю. поэтому живой mdf restic-ом не снимаю: сначала штатный bak, restic забирает уже файл. снапшот оставляю на логи и конфиги. check смотрит репу — блобы на месте, хэши сошлись. к sql это отношения не имеет. зелёный check на каше из mdf у вас как раз это и показал.

n1kita по ключу и 3389 — как писал. порт в интернет НЕ ОТКРЫВАЮ. ключ репы рядом с репой не лежит. restic отвечает за пожар и диск, а не за то, чтобы с улицы не зашли.

у кого bak на чистую так и не гоняли — лучше один раз прогнать сейчас, чем в день аварии.

pavel_63 вы с lexa92 уже третий круг повторяете одно и то же. живой mdf не таскать. check смотрит репу, sql — свой restore. это у обоих было ещё в первом сообщении.

pavel_63 писал:
vss на 2016 живую базу не вылечит

не вылечит ни на 2016, ни на 2019. --use-fs-snapshot не делает из restic бэкап sql, он только vss дёргает. у меня на linux без вашей Volume Shadow Copy та же гигиена: pg_dump в файл, restic забирает уже дамп. том, пока postgres слушает, не снимаю. кто restic-ом гоняет живой volume — получит ту же кашу из открытых файлов и зелёный check в подарок.

статья про linux на vps. win server 2016, планировщик от SYSTEM и bak на запасную в кабинете — это не дыра в гайде, это ваш отдельный цирк, и вы его сами выбрали)

репу restic держу не рядом с базой. иначе шифрование красивое, пожар один. restore на чистую — да, без этого «успешный бэкап» ничего не стоит.

а у кого volume в compose restic-ом на горячую уезжает — сразу дамп, или тоже ловили кашу?

pavel_63 запасная 2016 в кабинете — это проверка, не check. на bak ты ответил, третьего круга не будет.

kate_ekb писал:
это не дыра в гайде, это ваш отдельный цирк

дыра как раз там. статья про restic, про открытые файлы ни слова. кто снимет linux-рецепт на win server, получит зелёный check и кашу из mdf. vss не цирк, это первый шаг на винде. в тексте его нет.

по compose то же правило. живой volume postgres restic-ом не снимаю, linux это или win — без разницы:

pg_dump -Fc -f /var/backups/app.dump dbname
restic -r <repo> backup /var/backups/app.dump

том, пока база слушает, в репу не кладу. check снова зелёный и снова ни о чём.

restore дампа на чистую отдельно от check кто-нибудь гонял, или все уже через файл ходят?

n1kita по ключу добавлю, раз позвали. restic закрывает диск и снимок хостера. Открытый rdp он не лечит, тут вы правы с первого раза. 3389 в wan я НЕ ОТКРЫВАЮ: сервер слушает локально, заход с Keenetic через туннель. Пароль репы в менеджере на другой машине, не в каталоге репозитория и не в bat планировщика. Сняли том — без пароля restic не читается. Это и есть смысл шифрования, а не зелёный check.

Репу держу на том же vps, но на отдельном томе, не рядом с базами. Сгорит кабинет — bak на сервере останется. На прошлом хостинге ночной bak 1С ещё подвисал до утра, здесь пишется и задача отрабатывает. Бэкап, который не заканчивается, мне не нужен.

kate_ekb писал:
это не дыра в гайде, это ваш отдельный цирк, и вы его сами выбрали

kate_ekb, не цирк. Win server под 1С никуда не делся, бухгалтерия копирует linux-статью как есть. Про открытые файлы в тексте ни слова. --use-fs-snapshot не делает из restic бэкап sql, на 2016 и на 2019 одинаково. данная ошибка как раз отсюда. lexa92 поймал зелёный check на каше из mdf. Это цена пропуска в гайде, а не моего кабинета со запасной машиной. Цирк — класть живой mdf в репу и радоваться кружку :)

kate_ekb писал:
том, пока postgres слушает, не снимаю

тут не спорю. Правило одно: сначала дамп, потом restic. У вас pg_dump, у меня штатный bak. Живой том не кладу. Докер для sql мне не нужен, служба и так работает, yaml я не пишу. Volume в контейнере — ваш контур.

lexa92 restore bak на чистую 2016 гонял, не check. Запасная машина в кабинете, sql 2017 поднялся, 1С цеплялась, файловую отдельно открывал. Без этого «успешный бэкап» пустой звук.

как храню, чтобы не третий круг про vss:

• ночью sql пишет bak на отдельный диск, не в каталог базы
  
• планировщик от SYSTEM гоняет restic backup этого каталога плюс логи и конфиги. --use-fs-snapshot только на них, живой mdf не трогаю
  
• репа на другом томе, пароль не рядом
  
• раз в квартал restore на запасную 2016. check зелёный sql не поднимает
  
• заход только из туннеля, порт с улицы даже «на минутку» не открываю
  

borg под винду не ставил и не буду. restic 0.16.4 с github хватает.

у кого linux-гайд уехал на win server — restore bak на чистую уже прогоняли, или до сих пор только check смотрите?

pavel_63 репа на том же vps — соседний том, не бэкап. ляжет хост — bak и restic уйдут вместе.

pavel_63 писал:
Сгорит кабинет — bak на сервере останется

кабинет да. сам сервер — нет. вынеси репу с этой машины, иначе шифрование красивое, копия одна.

3389 закрыт, bak на чистую прогнан. на этом вопросов нет.

lexa92 соседний том на той же машине — это не offsite, тут ты прав. от rm по каталогу и от одного отъехавшего диска он ещё закрывает. хост лёг целиком — bak и репа уехали вместе, шифрование тут уже ни при чём.

lexa92 писал:
вынеси репу с этой машины, иначе шифрование красивое, копия одна

вынеси. не на «другой раздел». дамп пишется локально, restic уезжает на второй vps, в другую локацию. пароль репы не на том хосте, где лежит репа, не в compose и не в env, который бэкапится вместе с проектом. иначе сняли диск — сняли и ключ, дальше как без шифра.

по гайду поправлю себя. про открытые файлы там пусто, и это не только вин. я наехала на ваш 2016, а linux-volume postgres кладут в restic горячим и получают ту же кашу с зелёным check. это я пропустила. статья про restic на vps — dump перед бэкапом там должен быть. vss в linux-рецепт всё равно не впишу.

restic-образом pg_dump не делают: клиента postgres в том образе нет, это не баг. сначала дамп из контейнера базы, restic забирает уже файл.

services:
  db:
    image: postgres:16
    restart: unless-stopped
    volumes:
      - db_data:/var/lib/postgresql/data
      - ./backups:/backups
  backup:
    image: restic/restic:0.16.4
    restart: "no"
    depends_on:
      - db
    env_file:
      - restic.env
    volumes:
      - ./backups:/backups:ro
    entrypoint: ["/bin/sh", "-c"]
    command:
      - restic backup /backups/app.dump
volumes:
  db_data:

дамп отдельно, не из restic-образа:

docker compose exec -T db pg_dump -U app -Fc -f /backups/app.dump

depends_on не ждёт, пока dump допишется. backup я запускаю руками после exec, не в one-shot из depends_on. в сервис backup тома db_data нет, даже :ro. кто скопирует yaml и сунет volume «на всякий случай» — получит ту же кашу, что с mdf, только без вашей Volume Shadow Copy. check снова зелёный и снова ни о чём.

restore дампа гоняла на чистый postgres, не на том же хосте и не вместо check. один раз скрипт бэкапил каталог, пока dump ещё дописывался: check прошёл, база нет. я молодец, порядок в cron не посмотрела. поменяла — dump дописал, потом restic. с тех пор совпадает.

pavel_63 запасная 2016 в кабинете проверяет bak, это нормально. репа на том же vps при пожаре кабинета тебя спасёт, при падении сервера — нет. две копии на одной железяке — не бэкап. 1С и планировщик от SYSTEM тут ни при чём.

а у кого restic до сих пор смотрит в живой volume — dump сначала, или тоже ловили зелёный check на каше?

pavel_63 на 2016 compose не нужен. bak, планировщик от SYSTEM, restic с github. yaml оставь.

lexa92 писал:
yaml оставь

lexa92 оставлю. он для linux-compose, не для bak из планировщика)

pavel_63 3389 закрыт — холивар снят. ключ не в репе. restic без пароля это просто шум на диске.

kate_ekb писал:
хост лёг целиком — bak и репа уехали вместе

pavel_63 отдельный том на той же машине. сняли хост — оба в одной яме.

pavel_63 писал:
не цирк

pavel_63 сняла. дыра в гайде, не у тебя в кабинете. живой mdf в репу — да, цирк.)

kate_ekb yaml тогда твой. на 2016 его нет и не будет: bak из планировщика от SYSTEM, restic с github, пароль репы на другой машине. compose pavel_63 не подсовывай, он откроет его блокнотом и сломает на третьей строке.

дамп перед restic — это не вкусовщина. restic по живому тому postgres или по mdf даёт зелёный check и нечитаемый снимок. клиента postgres в restic-образе нет, и так и должно быть: сначала файл из контейнера базы, потом restic забирает уже файл. на 2016 то же самое, только файл это bak.

kate_ekb писал:
restic уезжает на второй vps, в другую локацию

репа на втором хосте, не на втором томе той же машины. соседний диск закрывает rm по каталогу. хост лёг целиком — bak и репа в одной яме, шифрование тут уже ни при чём. pavel_63 всё ещё держит репу рядом и считает, что сгоревший кабинет это offsite. кабинет да, сервер нет.

пароль не в compose, не в env проекта и не в bat планировщика. машина, с которой запускаешь restic, и машина с репой — разные. сняли диск — сняли ключ, дальше как без шифра.

проверка не «snapshot в списке»:

restic snapshots
restic restore latest --target /tmp/restore-test

открыл bak или дамп из /tmp. список снапшотов всегда зелёный. кружок всегда зелёный. это ничего не значит.

кто уже гонял restore не в /tmp — скинь, чем кончилось.

kate_ekb писал:
vss в linux-рецепт всё равно не впишу

не вписывай. на линуксе это дамп из контейнера, потом restic забирает файл.
живой том postgres в репу — зелёный check и каша, restic check всегда зелёный.
пароль не в compose. хост с restic и хост с репой — разные машины.

kate_ekb писал:
не в compose и не в env, который бэкапится вместе с проектом

kate_ekb restic/restic в том же yaml — пароль снова в env. backup рядом с db это не вторая машина. дамп из контейнера, restic забирает файл уже с хоста, где ключ. yaml оставь, restic из него вынь.