wara 1. 1с сумела восстановить свои данные
2. Access не сумел восстановить свои данные.
Вопрос в следующем (не вдаваясь в вопросы организации бэкапов и причин сбоя, хотя ,естественно, для точного ответа нужны более точные данные о том, что же случилось с серваком) :
1. Какая не очень навороченная субд содержит более развитые механизмы восстановления данных после сбоя сервера?
2. Возможные варианты, отчего произошла потеря данных (сценарии развития событий)?
1с - сумела, это DBF-ки? По своему опыту(начинал еще с Fox-1.0) при сетевых авариях в фоксе обычно теряется последняя запись и разваливаются индексы, что довольно просто лечится(а в 1с именно DBF и CDX файлы фоксовые) и это при условии, что диск не развалился, а был сбой или отключение света. Правда это все зависит от размера дискового кэша, а то и 1с не восстановит
Из бесплатных - я бы посоветовал PostgreSQL не ниже 8-ки. Там есть PITR - Point In Time Recovery(восстановление на указанный момент времени по журналам транзакций, тут писали про Oracle - в Postgres примерно то же самое), транзакции, настройки чекпоинтов и много еще чего.
Из платных - Sybase SQL Anywhere 5.x дешево и сердито. Есть и журналы транзакций и накат в случае падения и автобэкапирование и репликации- шевелится на всем практически - т е сервер БД работает под DOS/Win3.x/95/NT, OS/2,QNX 4.x. Правда наверное не купишь сейчас - не продают(всего-то 10 метров сервер занимает).
MS SQL - можно конечно, но монстряво будет.
По поводу вопросов физического развала дисков. Не используйте рейды -5 или страйпы. Содерите лучше RAID-1(зеркала) или вообще просто отдельные диски. При этом отдельный диск(зеркало) под файлы данных БД, отдельный под журналы транзакций(под WAL в Postgres или Transaction Log в Sybase SQL Anywhere), отдельный под бэкапы и отдельный под автобэкапы журналов транзакций(ну может еще один для сортворков и TMP файлов, в зависимости от сервера БД). Делать ежедневный бэкап БД(в онлайне или нет, зависит от сервера, но и Postgres и Sybase это позволяют делать)
Одновременно все диски сломаться не могут. Поэтому у вас всегда будет:
- либо полный бэкап и журналы транзакций
- либо рабочая БД(пусть и без журналов).
Либо организуете Hot Stand By (и PostgreSQL 8 и Sybase SQL Anywhere это позволяют сделать).
Все вышесказанное применительно к тому, что люди спрашивающие живут не в Москве, а именно в глубинке(сам такой)
Тут еще писали, что сервер БД не знает о физическом расположении файлов. Знает, и прекрасно знает. Играясь этим можно повышать как надежность, так и производительность. А вот пользователь(прикладной) абстрагируется от этого, он работает с таблицами, и ему по барабану на каких дисках эти таблицы в конечном счете находятся(а вот DBA не по барабану)

S.G.Отчего же не использовать? Райд-5, это когда из трех физических дисков делается один логический, и отказ любого одного физического диска не приводит к потери информации.
Что такое Рейд-5 - я знаю. Только при хранении критической информации нужна детерминированность. Т е используя зеркала каждый из дисков мы можем пользовать и в отдельности. Если у рейда-5 сдохнет контроллер - то нужен будет такой же для того чтобы оживить ваши данные, отдельно диски не поюзаешь. Если это нужно сделать быстро, а под рукой контроллера нет, что будете делать? (имеется ввиду финансовая информация, где простой очень критичен) . Причем бывают такие варианты(скажем взять стойку MA-8000 от HP и MSA-1000) собирай какие хочешь рейды , наборы и т п. Только вот загвоздка получается - захотите переставить диски из одной стойки в другую - а не получится, диски нужно инитить, чтоб увидеть и тю-тю вашей информации. И где вы будете рейд-5 собирать? Ну или обычные Mylex, у меня есть живой пример, человек очень верил в 5-е рейды, до тех пор пока не сбойнуло, так и пришлось пол дня заново забивать информацию. С зеркал данные можно слить и на обычном контроллере. Кроме того, при работе с зеркалами скорость чтения выше, т к контроллер может читать одновременно с разных зеркал разные участки данных.