Before posting, and to avoid disappointment, please read the following:

  • This forum is not for 2BrightSparks to provide technical support. It's primarily for users to help other users. Do not expect 2BrightSparks to answer any question posted to this forum.
  • If you find a bug in any of our software, please submit a support ticket. It does not matter if you are using our freeware, a beta version or you haven't yet purchased the software. We want to know about any and all bugs so we can fix them as soon as possible. We usually need more information and details from you to reproduce bugs and that is better done via a support ticket and not this forum.

Missing a function "delet on exist"

For technical support visit https://support.2brightsparks.com/
Post Reply
keltas
Enthusiastic
Enthusiastic
Posts: 17
Joined: Fri Sep 04, 2015 6:12 pm

Missing a function "delet on exist"

Post by keltas »

Hi, look at this mixed Mirror/Backup scenario:

Let SOURCE0 be a source directory with many subdirectories and files and
Mirror-mx it's monthly backup
Then is:
Mirror-m0 an exact copy of SOURCE0 at time m0
Mirror-m1 an exact copy of SOURCE0 at time m1, Mirror-m1 replaces Mirror-m0
Mirror-m2 an exact copy of SOURCE0 at time m2, Mirror-m2 replaces Mirror-m1
...

At the turn of the year, SOURCE is cleaned up and any scrap is deleted (unfortunately mostly a few files too many). This turns SOURCE0 into SOURCE1. To have a backup, Mirror-m12 is frozen and SOURCE1 is added as Mirror-Y0m12 to new SOURCE1.

Monthly mirroring will continue in the coming year
Mirror-m0 now contains an exact copy of SOURCE1 at Y1m1 incl. Mirror-Y0m12
Mirror-m1 now contains an exact copy of SOURCE1 at Y1m2 incl. Mirror-Y0m12
...

Since Mirror-Y0m12 no longer changes, this does not burden the mirroring process, but increases the memory required for mirroring. The storage needed would decrease significantly if all files in Mirror-Y0m12 are deleted at the turn of the year that are still unchanged in SOURCE2.

How can this process "delete on exist" be mapped with SyncBackPro?

Thanks - and a good health all over the ball
Keltas
keltas
Enthusiastic
Enthusiastic
Posts: 17
Joined: Fri Sep 04, 2015 6:12 pm

Re: Missing a function "delet on exist"

Post by keltas »

... sorry there may be some missleading wording (Don't konw how to get my posting changed).

replace "To have a backup, Mirror-m12 is frozen and SOURCE1 is added as Mirror-Y0m12 to new SOURCE1"
with "To have a backup, Mirror-m12 is frozen and added as Mirror-Y0m12 to SOURCE to become a new SOURCE1"
Best
Keltas
keltas
Enthusiastic
Enthusiastic
Posts: 17
Joined: Fri Sep 04, 2015 6:12 pm

Re: Missing a function "delet on exist"

Post by keltas »

Ok, one more try:
To be clear let's define the terms and describe the backup methods:

Code: Select all

Mirroring:      t(0): S(Fi,G) | D(Fj,H)   t(1): S(Fi,G) | D(Fi,G) 
Backing up:     t(0): S(Fi,G) | D(Fj,H)   t(1): S(Fi,G) | D(Fi/j,G,H) 
Sychronisation: t(0): S(Fi,G) | D(Fj,H)   t(1): S(Fi/j,G,H) | D(Fi/j,G,H)
with t(n) as a time sequence, Sorce S, Destination D, F,G,H as classes of PathNameExt named files, with i/j as an index to seperate versioned files, i.e. files that have the same file name (NamPathExt), but have non-name-forming properties such as size or timestamp. A file's version is irrelevant for mirroring. Only with backing up and synchronization does the result depend on the comparison of the versioning file properties. All three methods have in common that there is no loss of data on the source side and always loss of data on the destination side. A process that involves data loss on the source side is called "cleaning up" (which initially has nothing to do with data backup). While mirroring is consciously accepting files to be deleted, this is rather undesirable with the other two methods. The process in which you do not accept any loss of data on the destination side is called "archiving".

Fore sure is SB has a lot of cleanup functions all of which work wonderfully error-free and reliable - if you use them correctly (more on this later). In my view, however, an important clean-up function is missing, which, if it existed, would make SB an excellent archiving tool. Let's think of the amount of files on source divided into the important and the unimportant ones (without knowing at the moment which file belongs to which group) and carry out the following processes:

Code: Select all

Mirroring: t(0): S(Fi1,Fi2,G1,G2) | D(Fj1,Fj2,H)  ->  t(1): S(Fi1,Fi2,G1,G2) | D(Fi1,Fi2,G1,G2)
Copy:      t(1): D(Fi1,Fi2,G1,G2)                 ->  t(2): E(Fi1,Fi2,G1,G2)
Clean up:  t(2): E(Fi1,Fi2,G1,G2)                 ->  t(3): E(Fi2,G2)
Mirroring: t(3): E(Fi2,G2) | S(Fi1,Fi2,G1,G2)     ->  t(4): E(Fi2,G2) | S(Fi2,G2)
Now E is an archive of all the files by which t(6)S compared to t(0)S has been cleaned up. In the unlikely event that you find to have been too thorough in cleaning up, this archive can be put aside.

This for issue 'avoid misstakes':
I code a lot and save daily. Once a year I clean up in the manner described above so that I don't have to keep all unused projects in the backup all the time. This is always a concentration exercise and something goes wrong regularly. Things would be a lot easier if there was an aditional section "Wath to do if a file exists on source and on destination" containing a 'Delete on destination' = 'DELETE ON EXISTS' option. This function could then be activated once a year cneaning up the destination thus making it ready for an imediate move to an archive. The next normal mirror process would then restore the destination as usual.

Where we're at:
As I said, I don't want to complain, everything works very well. With regard to better stringency, I would on top like the following to be thought of:

- Option Profiling
Many of the SB options concern the distinction between Fi and Fj. Whether one version displaces another or not depends on the attributes to be used and their importance among themselves. The weighing up is generally so complex that the OS presents it to the user for decision at runtime. To automate this nevertheless, you can proceed as follows: The user defines the value of the versioning properties in a table and assigns the higher and lower value end of the table to either the displace or the non-displace function. To achieve that the user is presented a gridViewControl in which the version forming properties can be moved against each other. Once the order has been determined, a bit field is created for each file. In this bit field e.g. the archive bit is one bit wide and the date-time stamp is as many bits wide as it corresponds to the internal representation in the OS (or a space saving hash function ... that should be enough, everyone who has already coded knows what is being said here). In this way, common options can be summarized in an o_profile and, depending on the event, assigned to a backup profile.

- Custom Copy
Optional functions such as deleting empty files and directories, reassigning file rights, setting or deleting archive bits, manipulating Locale, Charset and Capital etc. are not actually part of a backup process. In order to know what you get, it is important the three methods mentioned produce exactly the result described. If you change this by activating certain optional extensions, you should no longer use their descritions, but e.g. the term 'CustomCopy'.

- NamPathExt Expand Option
As described above, you have to accept file deletion in the back-up and synchronization procedures to avoid file collisions. If the file name collision could be resolved, synchronization into an existing ARCHIVE database is possible. That would be the most comprehensive data backup imaginable. For this purpose, a service must be underlaid that automatically generates a file name component from a non-name but unitary property (as time stamp) and supplements the file name accordingly. (There are OS that can do this from home, e.g. VAX VMS (still alive!)).

The one or the other feature would maybe yes a complementary asset.
Best Keltas
Post Reply