[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ProgSoc] Hard disks
Hi John,
Seems like you are doing a lot of work keeping your backups in order.
Magnetic Tapes are the only real solution to storage currently used by
most businesses. Optical is too small and time-consuming. Machanical
fails eventually.
For example: directly connected to your server an autoloaded can swap
through magnetic tapes and perform your backups automatically. Tapes of
sizes up to 76gig are around nowadays. This way you can set up
grandfather/father/son backup schedules and take snapshots of your
information at regular intervals.
Problems include: speed, magnetic tapes are notoriously slow compared to
most other media; media failure, most companies only discover after a
disaster that the backup failed. You gotta do a test restore once you
*think* you've set it up right.
anyway, heres a link you migh find usefull:
www.snia.org (storage network industry assoc)
also, check tomshardware /storage
Cheers,
Kane
On Fri, 24 Jan 2003, John Elliot wrote:
> > I've been meaning to ask... all these people with 120GB hard discs,
> > how do you back them up?
>
> Good question.. I'd be interested to hear what other people did about
> managing their files.
>
> I have about 60GB of data on a 120GB drive. The drive is primarily a
> redundant data store on the 'file server' which currently holds over
> half a million files (It's a shame about the 681MB MFT!). I keep a
> working copy of most of my important files on another disk / computer,
> and then periodically dump them (all of them) to the 120GB disk. From
> there I zip up and burn the backup folders. I'm quite proud of myself
> since I actually _documented_ (*2) this procedure, I'm not necessarily
> proud of the procedure itself.
>
> I'd be happy to hear about how other people go about backing up their
> data, running a small IT business backups are definitely important, but
> they are also a big hassle since it seems to take so much time (and
> using my method: disk space / CD's).
>
> My backup methodology is basically to take 'version snapshots' during
> the day while working, and then a big 'backup snapshot' at the end of
> the week (or when something really important is finished), and pray that
> nothing goes bad on all of my computers at once during a time when no
> backups exist. It might sound silly, but it's about the most reasonable
> 'risk' vs. 'cost' solution I could come up with. It would be wonderful
> to know that every second of work was backed up and recoverable, but I
> don't have the time to manage this nor the funds to employ someone to
> manage it for me, so I do what I can which is basically, version -> copy
> -> compress -> burn. If I spent any more time managing backups I
> wouldn't have any time to do the work that needed to be backed up!
>
> I have been meaning to write some scripts that could help me manage
> this, but haven't got around to it yet, so I still plod away manually.
>
> The first 'version snapshot' helps me to avoid problems when files
> become corrupted, or when I do something I wish I hadn't (like changing
> the background colour of a graphic to blue only to find out that it
> looks terrible, etc.), the second snapshot will help me recover from
> serious hardware problems, fire, inadvertent use of fdisk :), etc.
> Corruption and user errors are problems that I face more regularly than
> failed hardware, so I find version snapshots to be useful at least
> weekly. I've never had to backup from an archive because of disk
> failure. I'm confident that I could, but it would probably take me at
> least a day to get back online and I would almost invariably lose _some_
> work.
>
> I manage backups of source controlled data and development databases
> differently. I use the archive facility in my source control software
> and I script databases every couple of days (so I can rebuild the schema
> easily) and if I have a database with important testing data in it I
> tend to 'detach and copy'. Once these types of backups are created I
> move them to my 120GB disk in the same way that I do my other files.
>
> Most of my business files that aren't under source control live in a
> local folder structure like this:
>
> \Work\<Client Name>\Project\<Project Name>\[dev | vX.X]
>
> I always work out of a folder called 'dev' and during the day I take a
> complete copy of the folder before I make any big changes or before I
> start work. This is so I can manually rollback changes if I have to.
> This only applies to items that I don't put under source control, I
> version pretty much everything that I do, but I only tend to put source
> code for important projects under source control. Even though I 'could'
> put everything under source control it would be largely impractical. I
> tend to ensure that my clients receive a copy of the most recent
> versions of projects as soon as practical as a poor mans way of
> achieving off-site backups.
>
> I was working on a word document that is the menu for my families café
> for a little while tonight, (*1) is an example of how I manage the files
> for this 'project'.
>
> The problem with this approach is obviously that I end up duplicating
> files (often needlessly) lots of times, first they are duplicated on the
> local machine in the project folder in the version folders, then they
> are duplicated when backed up to the server. This is particularly a
> problem for me when I have to work on Access databases that have both
> code and data in them, in this case I tend to create a 'development'
> version and cull most of the data, but managing releases is more
> difficult and time consuming then, so sometimes I just copy and paste
> and deal with the 100MB (or whatever) tax on the disk quota.
>
> The advantage is that it's easy to get at files quickly if I need an old
> version, and the versioning procedure can be quickly and easily applied
> to any type of file without relying on any form management software. I
> tend to manually cull duplicates from the development folder, since I
> only like to see files that are relevant.
>
> This way of managing files has saved my arse on numerous occasions, and
> is a result of the tragedies I have endured prior to managing my files
> this way. It's also very handy since I often find myself onsite using
> clients computers where their backup and version systems could be
> anything from non-existent, to poorly documented, to extraordinarily
> complicated and time consuming to setup and maintain. If there are other
> backup or version control mechanisms available I tend to supplement them
> with this method anyway, since it is often a lot easier to grab a file
> from a copy I made in the morning than to try and locate and recover the
> version of the file that I checked in and out several times during the
> day.
>
> As a 'standard' I start versions at v0.1 and then just increment by 0.1.
> If I receive a project from someone else I always keep an exact
> read-only copy of what I received in v0.0 for future reference if
> necessary. (This was particularly useful once when a client gave me an
> 'old' version of their source code claiming it was the latest version.
> When I released the version with the features they had requested they
> found that some old bugs had been reintroduced, since blame seems to be
> so important to people, especially when dealing with IT consultants, it
> was nice to be able to avoid it with the e-mail that explicitly asked if
> I had the latest code release and the copy of the wrong version of the
> source code. Managing the branching was of course then your typical
> nightmare.)
>
> I can type ALT F A END LEFT LEFT LEFT LEFT BACKSPACE <X> ENTER in my
> sleep, another favourite is CTRL-C CTRL-V F2 v<X>.<X> :)
>
> John.
>
> P.s. Those that bother reading this can tell from the timestamps on the
> older versions that I moved all my files from the old disk (thanks
> dubz!) to my new 120GB disk on 23/01/2003.
>
> (*1):
>
> Volume in drive W is Data
> Volume Serial Number is F0E7-3345
>
> Directory of W:\Park St Cafe\Project\menu
>
> 24/01/2003 12:38a <DIR> .
> 24/01/2003 12:38a <DIR> ..
> 23/01/2003 08:44p <DIR> dev
> 06/01/2003 09:05a <DIR> v0.0
> 06/01/2003 09:05a <DIR> v0.1
> 06/01/2003 09:05a <DIR> v0.2
> 06/01/2003 09:05a <DIR> v0.3
> 06/01/2003 09:05a <DIR> v0.4
> 06/01/2003 09:05a <DIR> v0.5
> 06/01/2003 09:05a <DIR> v0.6
> 06/01/2003 09:05a <DIR> v0.7
> 06/01/2003 09:05a <DIR> v0.8
> 06/01/2003 09:05a <DIR> v0.9
> 06/01/2003 09:05a <DIR> v1.0
> 06/01/2003 09:05a <DIR> v1.1
> 06/01/2003 09:05a <DIR> v1.2
> 06/01/2003 09:05a <DIR> v1.3
> 06/01/2003 09:05a <DIR> v1.4
> 06/01/2003 09:05a <DIR> v1.5
> 23/01/2003 07:38p <DIR> v1.6
> 0 File(s) 0 bytes
>
> Directory of W:\Park St Cafe\Project\menu\dev
>
> 23/01/2003 08:44p <DIR> .
> 23/01/2003 08:44p <DIR> ..
> 12/04/2002 08:13a 119,808 gst.xls
> 05/01/2003 12:06p 49,664 menu v2.4.doc
> 23/01/2003 07:43p 50,176 menu v2.5.doc
> 05/01/2003 12:06p 48,640 takeaway menu v1.3.doc
> 23/01/2003 08:44p 48,640 takeaway menu v1.4.doc
> 5 File(s) 316,928 bytes
>
> <snip>
>
> Directory of W:\Park St Cafe\Project\menu\v1.5
>
> 06/01/2003 09:05a <DIR> .
> 06/01/2003 09:05a <DIR> ..
> 12/04/2002 08:13a 119,808 gst.xls
> 11/05/2002 12:29p 43,008 menu v1.7.doc
> 14/05/2002 01:24p 37,888 menu v1.8.doc
> 14/05/2002 02:13p 37,888 menu v1.9.doc
> 12/09/2002 11:32p 44,544 takeaway menu v0.5.doc
> 13/09/2002 12:47a 49,152 takeaway menu v0.6.doc
> 13/09/2002 12:53a 49,152 takeaway menu v0.7.doc
> 7 File(s) 381,440 bytes
>
> Directory of W:\Park St Cafe\Project\menu\v1.6
>
> 23/01/2003 07:38p <DIR> .
> 23/01/2003 07:38p <DIR> ..
> 12/04/2002 08:13a 119,808 gst.xls
> 11/05/2002 12:29p 43,008 menu v1.7.doc
> 14/05/2002 01:24p 37,888 menu v1.8.doc
> 14/05/2002 02:13p 37,888 menu v1.9.doc
> 03/01/2003 09:29p 44,544 menu v2.0.doc
> 03/01/2003 11:28p 46,592 menu v2.1.doc
> 03/01/2003 11:54p 49,152 menu v2.2.doc
> 04/01/2003 08:11a 49,664 menu v2.3.doc
> 05/01/2003 12:06p 49,664 menu v2.4.doc
> 12/09/2002 11:32p 44,544 takeaway menu v0.5.doc
> 13/09/2002 12:47a 49,152 takeaway menu v0.6.doc
> 13/09/2002 12:53a 49,152 takeaway menu v0.7.doc
> 04/01/2003 05:47a 46,080 takeaway menu v0.8.doc
> 04/01/2003 05:53a 45,568 takeaway menu v0.9.doc
> 04/01/2003 06:11a 45,056 takeaway menu v1.0.doc
> 04/01/2003 06:17a 45,056 takeaway menu v1.1.doc
> 04/01/2003 08:22a 48,640 takeaway menu v1.2.doc
> 05/01/2003 12:06p 48,640 takeaway menu v1.3.doc
> 18 File(s) 900,096 bytes
>
> Total Files Listed:
> 138 File(s) 6,188,905 bytes
> 65 Dir(s) 57,389,445,120 bytes free
>
> ------------------
>
> (*2)
>
> CTI BACKUP PROCEDURES
>
> This file resides in the root directory on the mapped drive K:
>
> The K: drive is for backing up data on the CTI LAN.
>
> There are four types of data to be backed up to this drive:
> D: Docs (user documents)
> M: Mail (user email)
> W: Work (projects)
> A: All (all data files on drive. Docs, Mail, Work, etc)
> S: Sys (System backup - maybe excluding some OS files)
>
> When backing up data, place all files for the backup session in a folder
> named as follows:
>
> BKP <MACHINE> <ISO DATE> <HOUR><MIN> <DATA TYPE ID>
>
> For example:
>
> Docs folder from CTINB2 at 5:37pm on 1 July 2002: BKP CTINB2 2002-07-01
> 1737 D
> Mail folder from CTIWK2 at 7:17am on 17 Mar 2002: BKP CTIWK2 2002-03-17
> 0717 M
>
> Periodically data from the K: drive should be zipped and put on to CD.
>
> Before zipping the files and directory listing should be taken. To take
> the directory listing:
> 1. Open a command shell
> 2. Change directory to K: (cd k:)
> 3. Change directory to backup folder (e.g: cd "BKP CTINB2 2002-07-01
> 1737 D")
> 4. Dump directory listing to a file (e.g: dir /s > BKP CTINB2 2002-07-01
> 1737 D.dir)
>
> This can process can be accomplished automatically by dragging the
> backup folder onto:
>
> K:\dirlist.bat
>
> Note: Use the folder name and suffix ".dir" for the directory listing
> filename.
>
> An example of the contents of the directory listing file:
> ---------------------------------------------------------
> Volume in drive K has no label.
> Volume Serial Number is D838-473E
>
> Directory of K:\BKP CTINB2 2002-07-01 2016 D
>
> 30/06/2002 08:48p <DIR> .
> 30/06/2002 08:48p <DIR> ..
> .
> .
> .
>
> Directory of K:\BKP CTINB2 2002-07-01 2016 D\...
> .
> .
> .
>
> Total Files Listed:
> 6012 File(s) 455,830,505 bytes
> 1490 Dir(s) 11,695,546,368 bytes free
> ---------------------------------------------------------
>
> After the directory list has been created all files in the directory can
> be zipped up.
>
> Zip all files into a file with the same name as the folder they are in.
> (e.g. "BKP CTINB2 D 2002-07-01 2016.zip")
>
> Note: Use the folder name and suffix ".zip" for the zip filename.
>
> Once all files have been put into the zip archive, they can be deleted
> from the folder. Remove all files except the zip and dir file that were
> created during the backup process.
>
> When all files in a folder have been zipped the folder should be renamed
> with a prefix "Z" and all the non-zipped files should be removed,
> leaving only the two files in the folder.
>
> Zipped files are to be copied to CD and labelled as per the backup
> folder name.
>
>
> -----Original Message-----
> From: owner-progsoc@nospam.progsoc.uts.EDU.AU
> [mailto:owner-progsoc@nospam.progsoc.uts.EDU.AU] On Behalf Of arp
> Sent: Friday, 24 January 2003 12:06 AM
> To: marauder@nospam.marauder.tm; The Programmers' Society
> Subject: Re: [ProgSoc] Hard disks
>
>
> On Thu, Jan 23, 2003 at 11:26:16PM +1100, marauder@nospam.marauder.tm wrote:
> > * Gabriela Marcionetti <gabriela@nospam.progsoc.uts.EDU.AU> [2003-01-23
> > 23:14]:
> > > On Thu, 9 Jan 2003, Christian Kent wrote:
> > >
> > > > What's the size that gets the best $/MB ratio these days?
> >
> > I've been meaning to ask... all these people with 120GB hard discs,
> > how do you back them up?
>
> And if you don't, how hard will you cry when they die?
>
> arp
>
> -
> You are subscribed to the progsoc mailing list. To unsubscribe, send a
> message containing "unsubscribe" to progsoc-request@nospam.progsoc.uts.edu.au.
> If you are having trouble, ask owner-progsoc@nospam.progsoc.uts.edu.au for
> help.
>
>
> -
> You are subscribed to the progsoc mailing list. To unsubscribe, send a
> message containing "unsubscribe" to progsoc-request@nospam.progsoc.uts.edu.au.
> If you are having trouble, ask owner-progsoc@nospam.progsoc.uts.edu.au for help.
>
-
You are subscribed to the progsoc mailing list. To unsubscribe, send a
message containing "unsubscribe" to progsoc-request@nospam.progsoc.uts.edu.au.
If you are having trouble, ask owner-progsoc@nospam.progsoc.uts.edu.au for help.