Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MrHaugen]

I remember in the old days when I had one automatic backup approximately for each day or every other day, and then monthly on top of that. After I changed the backup path to my mapped backup share, this has almost completely stopped. I've now got perhaps 3-5 backups each month, as well as a January and February backup. It seems like the automatic backups have almost stopped. I remember before when I had automatic backups every other day. Now I have 3-5 each month. And most (if not all) of those are created manually before larger library maintenance. This worries me.

This is a library server that is online 24/7, so I would expect to have more backups than a few each month (as I mentioned, I think these are only manually created).
What can I do? What is wrong? How can I kick-start the automatic backups again?

[MrC]

Here's what I have.

Perhaps the share is offline or inaccessible to MC at times.  Try moving the backup directory to a local store that is always available.

[MrHaugen]

It's always available. I said it was a share, but that is not entirely correct. The disks are directly connected to the server. Other machines use the share, but that should be irrelevant.

I've changed the folder to my system disk now, but I do not understand how changing from one local disk to another could make any difference.

[Alex B]

The time stamp of the last automatic backup is stored in the registry. On startup MC checks this value and creates a new backup file if a certain amount of time has passed. I have not bothered to test this, but the timer seems to be set to about two days. If you don't restart MC will not create a new backup file.

[MrC]

If you don't restart MC will not create a new backup file.

If this is the case, it would explain what others have reported.

I'm hazarding that people expect automated backups to happen, well, automatically?  If one has to manually restart MC, so that a backup will occur, one might as well just perform a manual backup for certitude.

[Alex B]

It is the case. I have tested that part, just not the exact time interval.

EDIT

To check how it works you can monitor the "Last Backup Date" value or edit it manually to speed up testing.

For example, here's the registry key / value for one of my libraries:
HKEY_CURRENT_USER\Software\JRiver\Media Center 17\Library Specific\{0271DD42-DC87-45C4-9340-7F86FB847159}\Last Backup Date: 40978.506826
- This backup was done on March 10, 2012 at about noon (i.e. about 40978.5 days since December 31, 1899).

[MrC]

Perhaps a workable solution...

A slight modification to the MCC command:

  20011   MCC_BACKUP_LIBRARY

by adding a parameter (eg. 1 - no confirmation/always overwrite), supporting a default backup name in the standard backup location, which always overwrites an existing file, such as:

  Library Backup (via MCC).zip

This will provide users with the ability to automate backups on their own schedule either via a) a Scheduler task, or b) Windows Scheduler.  Then, they can backup the zip file, knowing its name, on a daily or periodic basis.

[MrHaugen]

If automatic backup is relaying on a restart of MC, this is really bad for library servers. It can go weeks and months before backup is happening here. I usually restart my MC only once a month when I restart the server for updates. In case of clients that is only put to sleep, there will also be huge gaps in the backups.

Could some alternative be added here? A scheduled backup for instance, in addition to check on startup? A standard of every two or three days would be fine. It would certainly avoid much of this questions asked lately.

[Scolex]

You could just schedule MC to shutdown and start using Windows Scheduler at some specified interval.
If you are not sure how to configure Windows Task Scheduler let me know and I can walk you through it.
It is really quite easy to do once you have done it a time or two.

[MrC]

I thought about that workaround and came to the conclusion it is limited and problematic.

1) MC requires manual intervention to confirm saving changed views.
2) MC may be in the middle of an all-night conversion/sync, so users must remember to manually disable the scheduled auto-shutdown.
3) Users can't control *when* the backup is performed, so can't be sure it is part of the day's backups.
4) Client's may be attached and running.
5) MC may be recording TV, or other stream via Scheduler.

etc...

[Scolex]

I thought about that workaround and came to the conclusion it is limited and problematic.

1) MC requires manual intervention to confirm saving changed views.
2) MC may be in the middle of an all night conversion/sync, so users must remember to manually disable the scheduled auto-shutdown.
3) Users can't control *when* the backup is performed, so can't be sure it is part of the day's backups.
4) Client's may be attached and running.
5) MC may be recording TV, or other stream via Scheduler.

etc...

1 - Since it appear he is using this machine as a server the view change confirmation should not be an issue.
2 - There is a setting for only running the task if the system has been idle for a selectable time.
3 - I assume you mean they can't configure it in MC and a simple restart of MC does not guarantee a backup.
4 & 5 - 2 should handle this, a test run should be done to be on the safe side though.

I agree completely that a no confirmation argument should be added to 20011.

[MrC]

Re: re: 1, 2, 4 & 5: "Backup? ... Maybe... if MC feels like it... and Window's isn't too tired... and the moon is not full... Meh, don't hold your breath, buster."   

[Scolex]

Someone PLEASE do something here I am turning bl *Scolex passed out from asphyxia* 

[MrC]

Breathe, man!  Breathe!

[Scolex]

Thanks for that I needed a good laugh, just call me Papa Smurf.

[MrHaugen]

I don't disagree that there might be ways around this. I just think it's not the best approach for me or other users in general. Automatic backup is a term which many thinks will do a backup now and then, no matter what. It's unfortunate if users think there will be backups, but there is none because of no restarts.

[rick.ca]

A slight modification to the MCC command...

The backup filename used by the command includes today's date. Why not just add a 'quiet' parameter so it can be scheduled? Although a system backup can maintain versions of the same file, not everyone who may be interested in this have that. And a backup that's replaced every day isn't much of a backup.

I don't know if it matters, but is the 'Last Backup Date' updated when the MCC is used?

[glynor]

Aha!  See... I never noticed this because I install most of the betas (therefore, MC restarts most weekdays).

I agree.  They should come up with some way to make the Automatic Backups happen without the user needing to worry about closing/reopening MC.

I imagine the problem is that they don't want to run the backup when the Library is in-use.  But, there has to be some way...

[MrC]

Some reasons for using a single filename:

 - easily script-able for coping (eg. foo vs. foo-{date})
 - avoids multiple versions on the same day: foo-{date}, foo-{date} (1), foo-{date} (2), etc.
 - avoids excessive copies

[rick.ca]

Some reasons for using a single filename...

I don't understand. Why would they be copied, and why would there be multiple versions on the same day? Surely one automatic backup per day is sufficient.

[MrC]

These are my thoughts...

Automated backup would go about doing its thing, creating files as it does today. It could be tweaked independently as per JR- or user-needs.

The problem with today's automated backup that users want to resolve, is a) its not predictable, b) it is not timely, and c) it is not automated.  Users know when their backup software runs; forcing a backup just prior to that run minimizes the potential size of change-set loss.  Otherwise, a backup might be days old, and quite stale.

The backup file name created via MCC should not use the same name space, so that there are no namespace conflicts.  A user knows the backup created via MCC was created via the most recent MCC command (i.e. probably the one just executed in the script).  Just knowing the simple path/name is sufficient to reference it.

By using a simple, unchanging name of the MCC-driven backup, a script can force an *immediate* backup, and then reference the backup zip file easily (mutable file names are harder to determine "latest" in a directory full of similar files; it is much easier for the script writer to tack on a date or qualifier to a non-mutable file name).

There can be multiple backups on the same day when a user manually backups a library on the same day when the auto-backup ran.  Currently, the user needs to enter a new file name via dialog.  If the user is supposed to always overwrite, why present a dialog at all?  If not, there will be multiple backups for the same day.

Or if the MCC backup was run more than once / day.  With the dated naming system, MC or the user must manage previous backup files.  And this defeats the point - the point of MCC backup is to obtain a single backup, now.  It can then be used, eliminated, or forgotten with no consequence.

Some people make lots of changes and maybe want, say, 2 backups per day.  I do this frequently during, say, testing out some new feature or idea.  I never overwrite today's early backup file, as that is another layer in the safety net.

[rick.ca]

I agree, except for this...

By using a simple, unchanging name of the MCC-driven backup, a script can force an *immediate* backup, and then reference the backup zip file easily

...which also seems to contradict or complicate your following (valid) points. Where is this script coming from and what is it for? If the user is capable of writing scripts and has some legitimate purpose, he can do so in a way that identifies whatever files should be included. But, more to the point, in the absence of this phantom script, the single file will be overwritten every time the command is used, and will therefore be of limited use.

It seems to me a quiet MCC command would provide an alternative addressing every possible shortcoming of the automated backup—if it names the files with the date and time. Doing so would eliminate the need to save them in a folder separate from the automatic backups. While there might be reasons for preferring separate folders, it would likely require introducing a separate MCC command (I assume the current one is the same internal command used by the current backup system), and just makes it's more difficult to choose a version for restoring.

Such a command could be scheduled to run at any frequency and at any particular time (e.g., immediately before the system backup). It could be invoked with a hotkey to create a backup for any particular reason (e.g., before attempting some risky operation). If the user wanted to overwrite an existing backup, or give the current one some descriptive name, they can still use the existing dialog.

[MrC]

Write both styles of scripts, and then you can let us know which one is much simpler to write.

[rick.ca]

Write both styles of scripts, and then you can let us know which one is much simpler to write.

Sorry, I thought I made it clear I don't understand the need or purpose of a script or what that has to do with the suggestion for a quiet backup command. Even if there is a legitimate need, I can't imagine how it can trump the need for reliable backup (i.e., multiple versions).

[Scolex]

If you want a small exe that can be scheduled to make your library backups. I can create it real quick using either a custom name of your choice or use the current naming structure. The name used if custom is embedded but I could configure it to come from an external text file (I think been awhile).
I have already tested an overwrite version and it works perfectly.

[rick.ca]

If you want a small exe that can be scheduled to make your library backups.

If this is addressed to me, no thanks. I could do something like that myself, if this were an issue for me. I'm just responding to the idea of a quiet MCC satisfying this and other backup needs. Others might be interested, however. Who knows when or if a change like this might be made...

[Scolex]

If this is addressed to me, no thanks. I could do something like that myself, if this were an issue for me. I'm just responding to the idea of a quiet MCC satisfying this and other backup needs. Others might be interested, however. Who knows when or if a change like this might be made...

It was addressed to anyone that might want to use it and lacks the ability to create it.

[Scolex]

Write both styles of scripts, and then you can let us know which one is much simpler to write.

I wrote both and they were equally easy, the overwrite is actually the longer script because it needs interaction twice (save as and overwrite confirmation vs just save as) so there are additional WinWait and Send commands.

[MrHaugen]

Writing scripts is one thing. I'll manage with that my self. But there are lots of users that would not touch such things. In either case, a silent backup command should be implemented.

I think there are two possibilities. Automatic backups should have some other properties, starting automatic backup more than just when starting MC. If this is difficult for some reason, we could have add a couple of scripts with the MC installation and document the use on wiki, as well as renaming the automatic backup to "Backup on restart". I do not think the latter is a great approach though.

[MrHaugen]

*bump*

Scolex, do you still have that backup script? I would be interested in using it. I could easily create one my self, but I'm just not sure how to handle the Ok button confirmation. I do not understand why commands like backup result in a OK popup.

Would it please be possible to look into an automatic way for backup without MC startup. Library server users are in a very bad spot here.