I was just looking to see if the 4D Backup docs mentioned taking advantage of the fact that not all the externally stored files would need to be recopied with each backup. I'd guess that external, automatic or not, would better fit the Time Machine model if 4D Backup backed up with separate files.
Keith - CDI > On Nov 15, 2016, at 5:42 PM, Wayne Stewart <[email protected]> wrote: > > Hi, > > I'm planning at some stage to reimplement external storage but when I > do I'm going to do it my way rather than the automatic way. > > Reasons? > > 1. I got burnt once > 2. If I know where the files are stored I can use them for something > else (e.g. #1 point Apache or the 4D web server at them, e.g. #2 store > them where Dropbox has access > 3. Ability to use Time Machine for backups and not 4D Backup (not > that I have anything against 4D backup but those pictures/pdfs don't > need to be included overtime). > > > Regards, > > Wayne > > > Wayne Stewart > about.me/waynestewart > > > > > On 16 November 2016 at 10:31, David Adams <[email protected]> wrote: >> I haven't followed all of the details in this thread, so apologies if I'm >> off the mark. (Not that following threads keeps me from wandering out into >> left field anyway.) First off, I'm glad that DvR was able to restore from a >> VM. >> >> I had a 4D V13 database that was going to store *lots* of scanned >> documents. I didn't want to keep them in the data file directly as it would >> become kind of pointlessly massive. I looked at the options, tried things >> out...and came away a bit worried about the outside-of-data-file story. >> Here's what we did, and it seems to be working fine: >> >> * Store the BLOBs (PDFs) outside of the data file using 4D's automatic >> feature. >> >> * Use a custom method to periodically (nightly, in our case) scan through >> the documents and export them by hand to a different location. >> >> So, as a backup to the 4D system, we've got an independent export of all of >> the documents organized in a hierarchical file system. Could we recover >> from a disaster this way? Yeah, but it would take some work. The folder >> names are based on the parent record IDs. Documents belong to something - >> the folder identifies 'something'. So, with a bunch of folder-doc walking, >> we could re-import all of the raw documents, but that doesn't get you any >> associated data about the document, if you have any. (You could write that >> out to a file next to the document, for what it's worth.) >> >> I know that all sounds kind of over the top, but it delivers these benefits: >> >> * A bit of peace of mind regarding a feature that, at the time, was new and >> not well field tested. (And, in retrospect, it sounds like our concerns >> weren't entirely unfounded.) >> >> * A snapshot backup that could itself be backed up with standard OS-level >> backup tools. >> >> * A hierarchical folder structure that can be drag-and-dropped onto a >> remote volume or served directly as a set of Web files. >> >> That last one actually was important for us. The same system is used in a >> few databases. In one, the documents are associated with people and need to >> be reviewed by various people. Once they get past an existing SSO, they can >> review the people. It's not that hard to spit out a page for each person. >> Since we've got a /personID/123.pdf sort of naming system, the Web page can >> reference the documents using src="123.pdf", which is so, so easy to deal >> with. >> >> Anyway, that's all kind of specific and has very little to do with the >> original problem (glad it was solved already!), but it worked out pretty >> well in this situation for not much work at all. >> ********************************************************************** >> 4D Internet Users Group (4D iNUG) >> FAQ: http://lists.4d.com/faqnug.html >> Archive: http://lists.4d.com/archives.html >> Options: http://lists.4d.com/mailman/options/4d_tech >> Unsub: mailto:[email protected] >> ********************************************************************** > ********************************************************************** > 4D Internet Users Group (4D iNUG) > FAQ: http://lists.4d.com/faqnug.html > Archive: http://lists.4d.com/archives.html > Options: http://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:[email protected] > ********************************************************************** ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
