In my case 65meg for MD3 solo practice and about 3gig for complete image of server drives C (OS) and D(programs and Data).
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Churches Sent: Wednesday, 29 March 2006 7:37 AM To: General Practice Computing Group Talk Subject: Re: [GPCG_TALK] Re: A typical cycle of backups Dr Hugh Nelson wrote: > much simpler, > burn a new DVD every day. > keep the most recent on site to rebuild after a server failure > keep the less recent off site in each of the principal doctors medical > bags to rebuild after the place burns down. As long as the copies in the offsite medical bags are encrypted... What are the typical back-up sizes for practices these days (complete and/or incremental backups)? Hugh, seems like your practice's data fits on a DVD. I am interested in order to assess the feasibility of using Amazon S3 Internet-hosted storage (or the Google equivalent when it is announced) for automated offsite encrypted backup copies. If the cost is just a few dollars per month, it might be a good bet. But if practice backup volumes are many tens of GBs, then it is not an option. Tim C > [EMAIL PROTECTED] wrote: >> A typical cycle for backups that is considered to over come most problems >> is >> 7 copies for each of the last 7 days >> 6 months for each of the last 6 months >> 3 years for each of the last 3 years. >> That may be a bit expesinve for HDD so tape is often used instead and >> also >> for the daily backups often only the changes are stored and not the whole >> filetsystem. >> jon >> >> Quoting Tim Churches <[EMAIL PROTECTED]>: >> >> >>> Michael Christie wrote: >>> >>>> Hello to all, >>>> We backup our Practice Mx software and Clinical software to a >>>> >>> removable >>> >>>> HDD which we take home every night. >>>> >>> As someone else commented, hopefully you use a series of removal HDDs >>> which you rotate. Otherwise you risk overwriting your only good backup >>> with a bad backup. This typically happens if your clinical system >>> database or other data files become corrupted on your server. You then >>> overwrite the last backup of uncorrupted files with a version containing >>> corrupted files. You then discover the corruption in your database and >>> decide to restore from backup, only to find that you only have backups >>> of corrupted versions of the database. Then you are stuffed. Hence the >>> need for backup media cycles. There are many schemes for this - the GFS >>> (somewhat sexist: grandfather, father, son) scheme was popular when I >>> last had to worry about such things five or six years ago. perhaps >>> someone can point to a good online discussion of back-up media rotation >>> schemes. >>> >>> >>>> In the clinical package there is a lot of scanned documents and >>>> >>> letters >>> >>>> to specialists which are simple Word files, most of which include Pts >>>> names and addresses and Medicare numbers, and lists of medical >>>> >>> problems >>> >>>> of individual pts. >>>> I was thinking, if say my car was broken into and the bag containing >>>> >>> the >>> >>>> HDD was stolen there is a risk of patients details being accessed. >>>> >>> Damn right. This has been discussed at length several times on the >>> former GPCG_TALk list, the archives of which are available online but >>> alas are not searchable, so I can't point you at that discussion. Pity. >>> >>> >>>> The Clinical and Practice Mx databases obviously could be broken into >>>> >>> if >>> >>>> one was a computer expert. (Unlikely I would think in the "normal" >>>> >>> car >>> >>>> thief.) But the Word docs are easily accessible by plugging the HDD >>>> >>> into >>> >>>> another computer.They are all in a folder called Docs. >>>> >>> I wouldn't count on the thickness of the thief. Things like portable >>> hard discs quickly find their way onto the second-hand computer gear >>> market, are traded multiple times in quick succession, and end up in the >>> hands of a university computer science student. Life's like that. >>> >>> >>>> Can my colleagues tell me what does a doctor do if this occurs? >>>> >>> Besides >>> >>>> the Police, who would need to be notified regarding this? >>>> >>> Your medical defence union, for sure. >>> >>> >>>> Would you need to contact ALL the patients from the surgery , say >>>> >>> 10,000 >>> >>>> people re the theft and that it is MAYBE possible that their medical >>>> details have been stolen. >>>> >>> I have argued that that would be teh ethical thing to do, but gee, it >>> puts you at grave risk of a class action by some of your patients, >>> particularly if some are lawyers or lawyers get wind of it. >>> >>> >>>> put an ad in the paper? Go on Today Tonight? >>>> >>> That would guarantee a class action against you, I suspect. Such an >>> action would not need to prove that the data were misused or even >>> accessed by the thief or whoever ends up with the HDD device - I >>> strongly suspect that just "proving" significant mental anguish at the >>> possibility that confidential medical details might be published on the >>> Internet would be enough to make the courts ruin your whole day. >>> >>> >>>> Is there a way of making access to the removable HDD difficult, say >>>> putting password access to the HDD? >>>> >>> Strong encryption, as Horst and others have pointed out, is teh >>> solution. >>> >>> >>>> This problem would obviously apply to stolen backup DVD's and tapes as >>>> >>> well. >>> >>>> How do we get around this? >>>> >>> Strong encryption of all confidential patient data written to all >>> removable digital media which is to be removed from the surgery and >>> which is not stored in the safe. >>> >>> The same applies to clinical databases hosted on laptops, of course. As >>> Horst mentions, an encrypting file system can be used. Even Windows >>> supports this - again, I have posted details of traps with this to bear >>> in mind on the former GPCG_TALK list, but those posts can't easily be >>> found now. Pity. anyway, you can find tutorials on file system >>> encryption with Windows on the Net via Google - but the default Windows >>> file system encryption is insecure - you need to tweak some Registry >>> entries so that you are forced to enter a password at boot time as Horst >>> notes in order to properly secure it. >>> >>> Tim C >>> >>> >>> >>>> _______________________________________________ >>>> Gpcg_talk mailing list >>>> [email protected] >>>> http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk >>>> >>>> >>> _______________________________________________ >>> Gpcg_talk mailing list >>> [email protected] >>> http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk >>> >>> >> >> >> -- >> Jon Patrick >> Chair of Language Technology >> School of Information Technologies >> University of Sydney >> Sydney, NSW, 2006, Australia >> >> ---------------------------------------------------------------- >> This message was sent using IMP, the Internet Messaging Program. >> _______________________________________________ >> Gpcg_talk mailing list >> [email protected] >> http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk >> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Gpcg_talk mailing list > [email protected] > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
