Claude Jones wrote:
Contrary to the subject line, BackupPC doesn't NOT back up the entire server, at least in WindowsLand. All files that are locked, which include things like your Outlook .pst file, and many operating system files, will NOT be backed up. I am too new to Linux to know how this issue plays out in the Linux world.
I Unix world, there are no mandatory file locks, only advisory locks. If application chooses to ignore the lock, nothing is preventing it from accessing the file (including removing the file that some other process keeps open).
So, backup application under Unix *can* backup the locked file, if it chooses to ignore the locks (or doesn't check for them). However, if the file was being kept open by some other application for writing, the content of the file might be corrupted/unusable after restore is performed (not to be confused with corrupted buckup or file, the backup and file will be OK, only the content might get corrupted).
There are couple of solutions to the problem:
- stop applications that keep file open, then do the backup
- simlar to above, if under LVM, make snapshot (instant operation), restart applications, do backup of snapshot, delete snapshot
- similar to previous (but redundancy lost while backup runs), if on software RAID1, flush dirty pages to disk, detach one submirror, do the backup, than reattach the mirror (Solaris has a nice feature that Linux lacks, Solaris allows submirror to be offlined, instead of detached, in which case no resync of entire mirror is needed, only changed blocks are synced, plus handy lockfs command that prevents new dirty pages to be created between sync and offline (or detach) operations, so you are guaranteed to have correct data on offlined (or detached) submirror).
- use application's backup module to do safe backups. most databases come with some kind of dump tool, some come with its own backup tools and/or modules for backup systems such as Legato Networker or Veritas Netbackup), and some can create snapshots. safe to use on live database as long as database supports transactions and/or locking *and* applications that access database are using them correctly (in other words, they don't leave database in unconsistent state between two transactions or wile tables are unlocked). if your database can't be brought down not even for milisecond, this might be the only option for making a backup of it.
-- Aleksandar Milivojevic <amilivojevic@xxxxxx> Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7
