«

Or, what happens when you're a rookie, and the boss is leaning on you to get
the problem fixed, NOW.
<http://weblog.infoworld.com/offtherecord/archives/2007/07/panic_mode.html>

Oh yes, it also helps to ensure your backups are up-to-date.

Lawrence D'Oliveiro wrote:
> Or, what happens when you're a rookie, and the boss is leaning on you to get
> the problem fixed, NOW.
> <http://weblog.infoworld.com/offtherecord/archives/2007/07/panic_mode.html>
>
> Oh yes, it also helps to ensure your backups are up-to-date.

In the days just before PC's etc, we used dumb terminals off a
mainframe. The mean sysadmin would not allow foreground compilations so
you had to submit the compilation to background and come back a bit
later. In particular the compiler listing was piped to a file for later
examination.

One guy came to me blind with panic - he had deleted his source file and
no backup! Fortunately he still had the output file and I was able to
'strip' the source code from the listing for him.

On Aug 3, 9:01 pm, Lawrence D'Oliveiro <l...@geek-
central.gen.new_zealand> wrote:
> Or, what happens when you're a rookie, and the boss is leaning on you to get
> the problem fixed, NOW.
> <http://weblog.infoworld.com/offtherecord/archives/2007/07/panic_mode....>
>
> Oh yes, it also helps to ensure your backups are up-to-date.

It also pays to try a restore occasionally, to see if your backups are
actually working. In one large computer company, the log file was
backed up every day. Unfortunately somebody changed the name of the
file without telling the minion who backed it up. The minion backed up
the old file for 6 months and filed the backup reports without
noticing that the record counts and date last changed had stayed the
same for 6 months.

In message < .com>, Matty F
wrote:

> On Aug 3, 9:01 pm, Lawrence D'Oliveiro <l...@geek-
> central.gen.new_zealand> wrote:
>
>> Oh yes, it also helps to ensure your backups are up-to-date.
>
> It also pays to try a restore occasionally, to see if your backups are
> actually working.

That's why my preferred form of backup is a simple rsync to another machine.
No funny backup archive formats, just a straight file-by-file copy, easy to
verify.

Lawrence D'Oliveiro wrote:
> In message < .com>, Matty F
> wrote:
>
>> On Aug 3, 9:01 pm, Lawrence D'Oliveiro <l...@geek-
>> central.gen.new_zealand> wrote:
>>
>>> Oh yes, it also helps to ensure your backups are up-to-date.
>> It also pays to try a restore occasionally, to see if your backups are
>> actually working.
>
> That's why my preferred form of backup is a simple rsync to another machine.
> No funny backup archive formats, just a straight file-by-file copy, easy to
> verify.
>
That's not very practical for Terabyte sized storage systems. OK for
small users, I'd guess. Even just running through a TB sized file system
and not copying anything can take hours.

Cheers,

Cliff

--

Have you ever noticed that if something is advertised as 'amusing' or
'hilarious', it usually isn't?

Enkidu wrote:
> Lawrence D'Oliveiro wrote:
>> In message < .com>,
>> Matty F
>> wrote:
>>
>>> On Aug 3, 9:01 pm, Lawrence D'Oliveiro <l...@geek-
>>> central.gen.new_zealand> wrote:
>>>
>>>> Oh yes, it also helps to ensure your backups are up-to-date.
>>> It also pays to try a restore occasionally, to see if your backups are
>>> actually working.
>>
>> That's why my preferred form of backup is a simple rsync to another
>> machine.
>> No funny backup archive formats, just a straight file-by-file copy,
>> easy to
>> verify.
> >
> That's not very practical for Terabyte sized storage systems. OK for
> small users, I'd guess. Even just running through a TB sized file system
> and not copying anything can take hours.
>
> Cheers,
>
> Cliff
>
2950 servers 4 TB disk pack configured in raid 5 takes just on 4 hours
to robo copy changes

Enkidu wrote:
> Lawrence D'Oliveiro wrote:
>> Matty F wrote:
>>> On Aug 3, 9:01 pm, Lawrence D'Oliveiro wrote:
>>>> Oh yes, it also helps to ensure your backups are up-to-date.
>>> It also pays to try a restore occasionally, to see if your backups are
>>> actually working.
>> That's why my preferred form of backup is a simple rsync to another
>> machine.
>> No funny backup archive formats, just a straight file-by-file copy,
>> easy to verify.
>
> That's not very practical for Terabyte sized storage systems. OK for
> small users, I'd guess. Even just running through a TB sized file system
> and not copying anything can take hours.

What other backup technique is faster ?

In message <>, Enkidu wrote:

> Lawrence D'Oliveiro wrote:
>> In message < .com>, Matty
>> F wrote:
>>
>>> On Aug 3, 9:01 pm, Lawrence D'Oliveiro <l...@geek-
>>> central.gen.new_zealand> wrote:
>>>
>>>> Oh yes, it also helps to ensure your backups are up-to-date.
>>> It also pays to try a restore occasionally, to see if your backups are
>>> actually working.
>>
>> That's why my preferred form of backup is a simple rsync to another
>> machine. No funny backup archive formats, just a straight file-by-file
>> copy, easy to verify.
>>
> That's not very practical for Terabyte sized storage systems. OK for
> small users, I'd guess. Even just running through a TB sized file system
> and not copying anything can take hours.

Depends on the number of files, rather than their size. rsync by default
only checks file size and modification date before deciding whether it
needs to do a full content comparison or not. (There is an option to
override this.)

collector«NZ wrote:
> Enkidu wrote:
>> Lawrence D'Oliveiro wrote:
>>> In message < .com>,
>>> Matty F
>>> wrote:
>>>
>>>> On Aug 3, 9:01 pm, Lawrence D'Oliveiro <l...@geek-
>>>> central.gen.new_zealand> wrote:
>>>>
>>>>> Oh yes, it also helps to ensure your backups are up-to-date.
>>>> It also pays to try a restore occasionally, to see if your backups are
>>>> actually working.
>>>
>>> That's why my preferred form of backup is a simple rsync to another
>>> machine.
>>> No funny backup archive formats, just a straight file-by-file copy,
>>> easy to
>>> verify.
>> >
>> That's not very practical for Terabyte sized storage systems. OK for
>> small users, I'd guess. Even just running through a TB sized file
>> system and not copying anything can take hours.
>>
>> Cheers,
>>
>> Cliff
>>
> 2950 servers 4 TB disk pack configured in raid 5 takes just on 4 hours
> to robo copy changes
>
Yeah. It depends on file size and numbers. It also means that you need
another 4TB somewhere. I copied 40 - 50 GB and it took about two hours.
That was from one file system to another.

Cheers,

Cliff

--

Have you ever noticed that if something is advertised as 'amusing' or
'hilarious', it usually isn't?

Mark Robinson wrote:
> Enkidu wrote:
>> Lawrence D'Oliveiro wrote:
>>> Matty F wrote:
>>>> On Aug 3, 9:01 pm, Lawrence D'Oliveiro wrote:
>>>>> Oh yes, it also helps to ensure your backups are up-to-date.
>>>> It also pays to try a restore occasionally, to see if your backups are
>>>> actually working.
>>> That's why my preferred form of backup is a simple rsync to another
>>> machine.
>>> No funny backup archive formats, just a straight file-by-file copy,
>>> easy to verify.
>>
>> That's not very practical for Terabyte sized storage systems. OK for
>> small users, I'd guess. Even just running through a TB sized file
>> system and not copying anything can take hours.
>
> What other backup technique is faster ?
>
If you find out, please let me know!

Cheers,

Cliff

--

Have you ever noticed that if something is advertised as 'amusing' or
'hilarious', it usually isn't?