SQLite Differential Backup
instead of backing up the entire database catalog i'd like to only backup the changes that happen to the catalog. Currently backups only backup the following:
"Backup only covers Catalog structure, metadata, and adjustments. Any original images (i.e. RAW, TIFF or JPEG files, etc) whether referenced or managed (stored physically inside the Catalog) will not be backed up."
https://support.captureone.com/hc/en-us/articles/360002520238-Backing-up-a-Catalog
This doesn't make a lot of sense. The backup should include the photos and it should be doing differential backups. It should backup any photo that was changed or added after the last modify date. This is an issue because now I have to utilize another piece of software to backup my photos. However, if I backup my photos after the database is backed up then I want to modify one of the photos in the backup I can't. If I want to utilize a master catalog and backup multiple catalogs from different users into a single catalog, I would want them all the databases to merge into the master database and for any picture changed. Otherwise, I might as well just backup the folder with copy and paste and not use your backup tool. I don't see a reason to backup adjustments without a photo reference.
It would also be helpful to have the option to have a Capture One process sitting in the background and we can set our backup times, not just when a user accesses Capture One and exits (they may not exit).
Also, it would be nice to be able to layer backup methods and set times for each backup method - Full Backup, maybe once a week. A differential or incremental backup once a day.
-
I don't need my backup software be able to develop perfect images, and I don't see a need for a perfect backup solution which fits everyone's use case within an image editing software. That's why dedicated backup softwares exist.
There are plenty of other things which should go into C1 or be improved, im my opinion.
To mention an example in the "catalog department", a master catalog of catalogs, or a master catalog of sessions (including optional sync of edits). I wonder if your envisaged setup of the master catalog of 20 users catalogs (from another post of yours) exists only in your imagination or has been tested already, especially with (assumed) high volume of images. This is the first thing I would do because when "giant catalog" and "C1" occurs in the same text this is usually when people complain.
Just my thoughts.
0 -
@BeO I disagree. This is just basic best practices for backups. I would expect when a backup happens the images are backed up. If backups are supported via the software the assumption would be any pertinent related file associated with the software would be backed up too - photos included, especially since there is a dependency on the existence of the images in order for the backups of adjustments and database to work. A centralized method of storing and accessing photos is, in general, best practice for any environment that is scaled.
that's also why this post is under 'Feature Request' and not a general complaint. I want better backups that make sense.0 -
I suppose that the Capture One catalog backup is intended to be used in conjunction with the regular system backups that it is assumed users will do as a matter of course. Those will backup the images.
Ian
0 -
Firstname,
Apart from my preference for a decent, separated backup solution, I have problems to imagine how C1 would deal with image deletions from the backup, especially if I have mutliple catalogs which imported parts of my image universe only.
So, woud catalog1 delete all images in referenced folders which are not imported into catalog1 but may reside in catalog2? What about sub folders? Or would a catalog only delete images which are in the catalog in the trash? What about "delete image from disk" then? Not supported?
Our money which goes into C1 would be better spent to implement image related features, bug fixes or improvements, performance, or maybe a new catalog database structure from the ground up, solving caching (display lag) issues, better softproof, etc. etc. because most of these things cannot be done by an external application, but backing up images can. There are even good free backup solutions.
Nothing wrong with requesting that here, nothing wrong with discussing and disagreeing. Cheers.
P.S. My advice still holds, if you are the Firstname from a post in the scripting forum who want to have a yearly master catalog for 20 C1 users then I suggest you mock the envisioned no. of images and test the solution, especially if the users will produce a high number of images.
0 -
OP,
If you force users down the "differential backup" route there is not much real benefit to them in the modern equipment era with large volumes of relatively cheap storage available. But there could certainly be more pain should they ever need the backup by forcing extended restore processing rather than simply renaming a previously backed up catalog file.
The images are a different matter from a storage perspective and should be handled differently. However on the basis that Capture One will never change an "original" file (although output files from C1 are now excepted from that rule) the individual source files could be thought of as a never changing archive in that the files may be added and deleted but never changed. So long as there is a back up of the file somewhere (possibly off-site) there seems to be little point in constantly checking it for "backup" status.
If I was part of a large corporation with an IT department doing the restores for me (and able to do them instantly on demand) I might see some rare benefit from an incremental backup. But not being in that supported state I'm less convinced of the benefit compared to what is offered. Indeed as sessions user there is no auto backup offered other than for original images if one is importing.
I use an irregular copy-over to a NAS as a partial backup solution and accept the risk that might come from having (currently) no significant offsite backup. This, in effect, freezes a project once completed unless I return to it for some minor additional work. I would usually do that working directly with the NAS-stored data. I think it may be more practical to work that way with a Session (or catalogues used like sessions, one per project for example) than it would be running a single main catalogue but the idea of incremental backups within the application when using catalogues would not have much attraction as a good use of development hours for the reasons that BeO suggests.
Of course that is just my opinion.
0
Post ist für Kommentare geschlossen.
Kommentare
5 Kommentare