hi ya joao
On Sat, 25 Dec 2004, Joao Clemente wrote:
> I have the notion of what an incremental backup is... it would be
> keeping the "delta" from the last state, but how is this done in
> practice?
in real life ... very few people check that backup does in fact work
by trying to restore ALL their data on a virgin disk
- in doing that simple rebuild, you will find all kinds
of problems with ones current backup scheme, or at least
things you care about
> Is it done with "tar" with some flag? Can we compress the
> backups (tar.[gz|bz2])
i always use tar zcvf backup.date.tgz "list of files"
- some folks do NOT like compressed backups
- warm backup servers, like carl's initial post, cannot use "tgz" files
- but for sanity sake, to know what changed on what day,
it's always a good idea to keep a log of what changed when
( separates teh men from the boyz )
> or it needs to be uncompressed to create the
> "delta"? Can we do a "2nd_delta" from a "backup + 1rst_delta"? Or the
> "2nd_delta" is created directly from "backup" therefore overriding the
> need for the "1rst_delta"?
separateing the men from the boyz....
- you always backup from the last full backup
and you "UNCONDITIONALLY GUARANTEE" that full backups
does in fact worked
- i use 3 methods to recreate a full backup at any given point
time ( daily backups, weekly incrementals, monthly incrementals)
- incrementals used to recreate full backups untill "today"
from a working good full backup 3 months ago ..
when you just found out today, that last 2 monyhs of full
backups was never done for goffy reasons but
incrementals was working .. etc
( or incrementals died but full backups working )
- or if both full and incremental backups failed,
since somebody pulled the power plug or the disks crashed
or ??? ... gazillion ways for backups to fail since nobody
watch it constantly
> Maybe its not even done with "tar"... I keep thinking on "diff's" and
> "patch's" but maybe its not the same here.
rdiff backups is good ..
- it'd be super fast to only backup the changed inode
( sorta bleeding edge stuff in linux land )
- remembering, that backups has to be 100% guaranteed that
you can recover corp data at any date in the past
> If one needs the (uncompressed) initial tar available from a backup to
> find the "delta", this means we need a "2xN" disk, where "N" is the info
> we have in disk.. so you could only do incremental backups in a disk
> with less than 50% occupation.. rigth or wrong?
depends on data types
- some data... you can compress 10:1
- other data, you cannot compress any more
( *.bz or *.mpeg or *.lib would be hard to compress further )
- most people do NOT have 100% disk utilizations
- usually people have older smaller capacity disks
than what is currently available today for a reasonable
backup budget
- i can usually store 6months - 1 year of full backups
for all servers
A backups to B
B backups to C
C backups to D
A, B, C backups to (warm,live) MasterBackup
> What do you say? Pointer to right commands/howto's? Thanks
some/lots of the backup examples
Linux-backup.net
- easiest backup ( run it from cron )
-- always manually mount the backups ...
- it avoids the "rm -rf /" that your backup will
be left unaffected since it's not automounted
#
# last 8 days of changes, do it daily
#
mount /mnt/BACKUP ; tar zcvf /mnt/BACKUP/datecode.daily.tgz \
` find /etc /home -mtime -8 -print" ; umount /mnt/BACKUP
#
# last 90 days of changes, do it weekly
mount /mnt/BACKUP; tar zcvf /mnt/BACKUP/datecode.weekly.tgz
` find /etc /home -mtime -95 -print" ; umount /mnt/BACKUP
- use a script to exclude and filter out crap you
do not want in the backups
- pick your backup media
- backup to tape
- backup to disks
- backup to cdrom/dvd
- backup to laptop/palmtop or vice versa
- understand how your backups will fail
- disk crash
- bad nic card
- bad hardware ( bad memory, bad disk, bad computer room policy)
- janitor/you pulling and wiggling the plug
- choose what you want to backup
- /etc ?? /home ??
- windoze backup to linux or linux mount and backup windoze shares
...
- know how to restore a full system from backups only
onto a brand new disk or raid array
- do not emulate or pretend that backups works
if i did this and that ... "do it for real"
and diff that disk against the original it supposed
to represent and be a warm backup of the master
- use a backup method that you understand and know
what it will backup and why and when it will fail
c ya
alvin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
