Re: [MBZ] OT MDB files
> One thing to note. If an SSD is in use and power is lost, your data is > probably going to be corrupted. Unless you are using an enterprise grade > drive. For critical data I trust only rotating magnetics. SSD's are fast, but they're cheap and sloppy now. You can't even find any technical specs on most of 'em. -- Jim ___ http://www.okiebenz.com To search list archives http://www.okiebenz.com/archive/ To Unsubscribe or change delivery options go to: http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com
Re: [MBZ] OT MDB files
One thing to note. If an SSD is in use and power is lost, your data is probably going to be corrupted. Unless you are using an enterprise grade drive. Rick ___ http://www.okiebenz.com To search list archives http://www.okiebenz.com/archive/ To Unsubscribe or change delivery options go to: http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com
Re: [MBZ] OT MDB files
Excel may be able to open or at least import data from an .mdb file. On Mon, Dec 4, 2023, at 09:31, dan penoff.com via Mercedes wrote: > No need to pile on over the backup issue. Like Jim, use multiple types > of media and multiple backup strategies. I had a catastrophic loss in > the late 90s that I learned my lesson on. I had backups, but like this > situation, I had legacy files that couldn’t be restored. > > I think .mdb is the file extension for Access, which is bad news, as > Access didn’t play nice with anything else that I can recall. > > -D > >> On Dec 3, 2023, at 12:08 PM, Jim Cathey via Mercedes >> wrote: >> >> That sucks, sucks, sucks, but only hammers home the lesson that you >> need to know your tools, and have strategies in place for protecting >> important >> data. Shit Happens, and that's no lie. For example, is a database the best >> tool for your job? I use a plain text-file system, which means zero >> dependence >> on any particular tool. I don't get database access, but then again I have >> no real >> need to run complex queries on the stored data. Mostly I just need a log, >> and I >> use grep to find things in it on occasion. It's been entirely satisfactory. >> >> Our family computing resources are protected by Time Machine (Apple), sent to >> a RAID storage server that itself has periodic rotating offsite/offline >> backups. It >> would take an asteroid strike or the equivalent to get it all, though I >> could ultimately >> lose the last quarter's data to a house fire or something. If I cared more >> I could exploit >> the cloud or something to get an additional layer of protection, and perhaps >> less exposure >> to loss. Or up the offsite update frequency. (Which reminds me, it's >> time...) >> >> At work we have multiple layers of backup in place, including some >> additional ones to >> protect the critical database from ransomware. The trickiest part in any >> loss scenario >> might be figuring out which recovery strategy (from the playbook) is the >> best one. >> Time to recover is a factor in a business that probably doesn't really apply >> to a private >> situation. >> >> If it's important you need to whip up some threat scenarios, and then design >> responses >> to them, and then implement. As a first rule of thumb, ALL your data should >> NEVER be >> on the same medium. That means backups absolutely need to go to a different >> device. >> And that's just the beginning. >> >> For those enamored of subscription-based cloud services, a big threat is the >> company >> going out of business. Do you have a response? >> >> -- Jim >> >> >> ___ >> http://www.okiebenz.com >> >> To search list archives http://www.okiebenz.com/archive/ >> >> To Unsubscribe or change delivery options go to: >> http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com >> > ___ > http://www.okiebenz.com > > To search list archives http://www.okiebenz.com/archive/ > > To Unsubscribe or change delivery options go to: > http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com ___ http://www.okiebenz.com To search list archives http://www.okiebenz.com/archive/ To Unsubscribe or change delivery options go to: http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com
Re: [MBZ] OT MDB files
No need to pile on over the backup issue. Like Jim, use multiple types of media and multiple backup strategies. I had a catastrophic loss in the late 90s that I learned my lesson on. I had backups, but like this situation, I had legacy files that couldn’t be restored. I think .mdb is the file extension for Access, which is bad news, as Access didn’t play nice with anything else that I can recall. -D > On Dec 3, 2023, at 12:08 PM, Jim Cathey via Mercedes > wrote: > > That sucks, sucks, sucks, but only hammers home the lesson that you > need to know your tools, and have strategies in place for protecting important > data. Shit Happens, and that's no lie. For example, is a database the best > tool for your job? I use a plain text-file system, which means zero > dependence > on any particular tool. I don't get database access, but then again I have > no real > need to run complex queries on the stored data. Mostly I just need a log, > and I > use grep to find things in it on occasion. It's been entirely satisfactory. > > Our family computing resources are protected by Time Machine (Apple), sent to > a RAID storage server that itself has periodic rotating offsite/offline > backups. It > would take an asteroid strike or the equivalent to get it all, though I could > ultimately > lose the last quarter's data to a house fire or something. If I cared more I > could exploit > the cloud or something to get an additional layer of protection, and perhaps > less exposure > to loss. Or up the offsite update frequency. (Which reminds me, it's > time...) > > At work we have multiple layers of backup in place, including some additional > ones to > protect the critical database from ransomware. The trickiest part in any > loss scenario > might be figuring out which recovery strategy (from the playbook) is the best > one. > Time to recover is a factor in a business that probably doesn't really apply > to a private > situation. > > If it's important you need to whip up some threat scenarios, and then design > responses > to them, and then implement. As a first rule of thumb, ALL your data should > NEVER be > on the same medium. That means backups absolutely need to go to a different > device. > And that's just the beginning. > > For those enamored of subscription-based cloud services, a big threat is the > company > going out of business. Do you have a response? > > -- Jim > > > ___ > http://www.okiebenz.com > > To search list archives http://www.okiebenz.com/archive/ > > To Unsubscribe or change delivery options go to: > http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com > ___ http://www.okiebenz.com To search list archives http://www.okiebenz.com/archive/ To Unsubscribe or change delivery options go to: http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com
Re: [MBZ] OT MDB files
That sucks, sucks, sucks, but only hammers home the lesson that you need to know your tools, and have strategies in place for protecting important data. Shit Happens, and that's no lie. For example, is a database the best tool for your job? I use a plain text-file system, which means zero dependence on any particular tool. I don't get database access, but then again I have no real need to run complex queries on the stored data. Mostly I just need a log, and I use grep to find things in it on occasion. It's been entirely satisfactory. Our family computing resources are protected by Time Machine (Apple), sent to a RAID storage server that itself has periodic rotating offsite/offline backups. It would take an asteroid strike or the equivalent to get it all, though I could ultimately lose the last quarter's data to a house fire or something. If I cared more I could exploit the cloud or something to get an additional layer of protection, and perhaps less exposure to loss. Or up the offsite update frequency. (Which reminds me, it's time...) At work we have multiple layers of backup in place, including some additional ones to protect the critical database from ransomware. The trickiest part in any loss scenario might be figuring out which recovery strategy (from the playbook) is the best one. Time to recover is a factor in a business that probably doesn't really apply to a private situation. If it's important you need to whip up some threat scenarios, and then design responses to them, and then implement. As a first rule of thumb, ALL your data should NEVER be on the same medium. That means backups absolutely need to go to a different device. And that's just the beginning. For those enamored of subscription-based cloud services, a big threat is the company going out of business. Do you have a response? -- Jim ___ http://www.okiebenz.com To search list archives http://www.okiebenz.com/archive/ To Unsubscribe or change delivery options go to: http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com
