Модератор: terminus
Код: Выделить всё
expected next file 2567, got 786
ABSOLUTE
FREEBSD
2ND E D I TI O N
THE COMPLET E G U I DE TO FREEBSD
by Michael W. Lucas
dump(8) is a disk-block backup tool. In some ways, it looks similar to tar(1),
but the significant difference is that dump is aware of the underlying filesystem
and takes advantage of the filesystem layout. We’ll talk more about
filesystems in Chapter 8, but for now, all you need to know is that a filesystem
is the scheme by which zeroes and ones are arranged on the physical hard
drive. dump is specifically integrated with FreeBSD’s UFS2 filesystem. New
sysadmins aren’t as likely to be familiar with dump as with tar, but dump is
more efficient and safer than tar. When you have a choice, use dump.1
One drawback of dump is that it works on filesystems, not on files. You
can’t dump /etc unless you want to dump all of the root partition. You can
restore individual files, however.
On the positive side, dump uses separate programs for backup and
recovery (dump(8) and restore(8), respectively). This means that you don’t
have to worry about confusing your flags and accidentally overwriting the file
you’re trying to recover from. dump is considerably faster than tar, too.
User Control
One significant advantage of dump(8) is that users can offer a certain
amount of advice to the program. For example, they can mark a file as
“do not dump,” and it won’t be backed up. Many users have stuff that they
don’t care about, and they will happily agree to not back those things up if
it means that the data they do care about is backed up.
To set the nodump flag on a file, use chflags(1):
#chflags nodump filename
When you set the nodump flag on a directory, everything in or below that
directory is not backed up. For example, I use chflags to avoid backing up my
downloads directory to save time and space during backups, because I can
always download those items again.
dump Levels
One of dump’s more interesting features is its ability to do very specific
incremental backups via dump level, a number from 0 to 9. The default
dump level is 0, which tells dump to copy everything that isn’t marked nodump.
Higher levels of dump mean, “Back up any files that have been changed or
created since a dump of any lower level.” This level pattern means that you
can do full backups, differential backups since a full backup, or incremental
backups—just by changing the dump level.
1 Some sysadmins will disagree and insist that tar(1) is better. This is an argument of epic
proportions in the Unix community, and any recommendation I make will undoubtedly anger
the people devoted to the other tool. I firmly believe that the only way to finally settle this is for
all the people who are fanatic devotees of one tool or the other to meet on the field of honor at
dawn and settle it with their weapon of choice. The rest of us will just get on with our lives.
For example, say you start each Monday with a level 0 dump. On Tuesday
you could do a level 1 dump, and only files that changed since Monday will
be backed up. If you perform a level 2 dump on Wednesday, everything that
changed since Tuesday will be backed up. On the following Thursday, you
run another level 1 dump. Any files that were changed since Monday will be
backed up, including files that were backed up on Wednesday.
I recommend using only level 0 dumps because they are far, far easier to
restore from than a series of incremental backups. Level 0 dumps take longer
to run than incremental dumps, however, and take up more tape space, but
in most cases reducing recovery time is more important than the cost of tape.
With proper planning, you can run level 0 dumps overnight.
Specify the desired dump level as a command-line argument; for example,
run a level 2 dump with dump -2.
dump, Tape Drives, and Files
Unfortunately, dump(8) and restore(8) don’t recognize $TAPE and just send
everything to /dev/sa0. You can specify a particular tape drive with -f. Similar
to tar, dump lets you point -f at a file. While dump files are not generally
suitable for distribution in the same way tar files are, it’s a great way to
experiment and become familiar with dump.
Before dump runs a backup, it attempts to calculate how many tapes it
will need for the backup. Unfortunately, dump’s ability to automatically detect
the size of a tape has weakened over time. When dump was new, a 1MB tape
drive was serious business and every vendor had their own standards for tape
formats. Today, tape drives are much more generic and standardized, and
vendors must interoperate more freely. The size of tapes has also dramatically
changed: For example, I’m writing this book using a 40GB tape drive discarded
by a previous employer for the blameless but irremediable crime of being too
small to bother keeping. Between enhanced standardization and dramatically
expanded capacity, dump has a really hard time figuring out how large a
tape is. The best way to deal with this problem is to tell dump to not bother
calculating the size of the tape; instead, just run until the tape hits the end,
and request another tape then. Use the -a flag for this.
dump and Live Filesystems
One problem with backups is that on a working machine, the filesystem tends
to change while the backup is running. This isn’t a problem with filesystems
where the data is fairly static, or where changes in one part don’t affect
changes in another, but it is a serious issue when your data is highly dynamic,
volatile, and/or interrelated. Many databases have this problem. You probably
don’t want to shut down your database server just to get a good backup, and
you might not even be able to dump the database to a file so you can get a cold
backup. Dump takes advantage of UFS2’s snapshot facility to get around this
and ensure that a backup is internally consistent. We’ll cover snapshots in
Chapter 8, but for now, just remember that a snapshot is an image of a disk at
an exact moment in time. Even as the data on the disk changes, the snapshot
remains unchanged and static, so you can back it up easily.
Specify -L to dump a snapshot. If you back up a live UFS2 filesystem
without using this flag, dump will complain and tell you to use -L.
This will not eliminate the “live database” problem, of course; just because
the filesystem is consistent doesn’t mean that the database on the filesystem
will be consistent as well. But you can shut down the database for a moment,
start the dump, and start the database again, letting dump copy the snapshot
taken while the database was shut down. This reduces the downtime window
for backups to only a second or two.
Как именно нужно разобраться с dump'ом? Я делал бэкапы такой командой (пример):вот-вот надо с дампом разобраться так как при использовании режима -L он бекапит снепшот UFS, а tar так не умеет.
Код: Выделить всё
dump -0 -a -u -f /backup/usr0.img -L /usrКод: Выделить всё
dump -3 -a -u -f /backup/usr3.img -L /usrне знаю, я как-то с бакулой подружился и юзаю в основном ее, дампом не пользуюсьAbyrvalg писал(а):Как именно нужно разобраться с dump'ом? Я делал бэкапы такой командой (пример):
Логи бы посмотреть, может что-то где-то он оставил, т.к. масса народа юзает дамп и я вроде до сих пор не слышал о его плохой работе, думаю, что все-таки проблема конкретно у тебя. Вообще хорошая практика время от времени проверять бэкапы.
Подтверждаю, юзаю, полностью испытан в боевых условиях (dump restore), пока доволен.princeps писал(а):масса народа юзает дамп и я вроде до сих пор не слышал о его плохой работе
а можно подробней как это работает, ну или статейку какую-нибудь почитатьfreeman писал(а):Подтверждаю, юзаю, полностью испытан в боевых условиях (dump restore), пока доволен.princeps писал(а):масса народа юзает дамп и я вроде до сих пор не слышал о его плохой работе
Ну как то так http://www.lissyara.su/?id=1091rnd писал(а):а можно подробней как это работает, ну или статейку какую-нибудь почитатьfreeman писал(а):Подтверждаю, юзаю, полностью испытан в боевых условиях (dump restore), пока доволен.princeps писал(а):масса народа юзает дамп и я вроде до сих пор не слышал о его плохой работе
Код: Выделить всё
dump -0 -a -u -f /backup/usr0.img -L /usrКод: Выделить всё
restore rf /backup/usr0.imgЭто был хитрый способ привлечения вниманияну вот, а сразу бочку катить на хорошую программу
Код: Выделить всё
expected next file 16207, got 23
Ну неплохо... а скриптик можно увидеть?ProFTP писал(а):я для себя написал скрипт:
1) ищу каталог пользователя в системе (хостинг, сайт)
2) дамплю mysql (базы пользователя или пользователей, которые ассоциируются с пользователем в системе)
3) архивирую каталог пользователя и дамп mysql, ставлю пароль, сохранаяю пароль где-то (или без пароля)
4) переливаю по фтп
5) и сделал загрузку типо на подобные rapidshare.com или на другие быстрые шары, так же можно отправить пароль и ссылку пользователю на email - пускай сам ковыряет
Все скрипты к dump\tar\restore уже давно написали в мерилендском университете и называется это amanda, если уж вам надо какие-то сложные схемы использовать, а не просто снять дамп ФС.
