Small backups of Flame working files

At our post house, we are looking at options to back up Flame working files for emergency recovery.

Currently, all jobs are archived with cache to LTO, which works well. But, in case the LTO machine explodes, we’re thinking it would be good to set up an automatic backup of the Flame setups only - no media required.

  1. I believe that backing up /opt/Autodesk should do the trick, right? So worst worst case, if we lose an archive, we can recover rushes from the agency and use /opt/Autodesk to rebuild Flame projects?

  2. Does anyone have a suggestion of software that we can use to automate backup from /opt/Autodesk to a Synology drive, nightly, across multiple Mac and Linux systems?

Thanks!

1 Like

On Linux rsync is part of the OS and all you need. On Mac you may be able to get rsync to work, or if you’re looking more for an app, SyncTime is basic but does the trick. GoodSync is more versatile but probably overkill. GoodSync does exist on both OS if you need uniformity.

1 Like

Thanks I’ll check these out.

Another question - do I need to back up the whole /opt/Autodesk folder? Or could we rebuild a project using just /opt/Autodesk/project?

1 Like

I was wondering why you would take the entire /opt/Autodesk/ folder.

You would only need /opt/Autodesk/project/ but this is just a back up of setups. I have never tried to restore a project from here. Not too sure where you would find anything like timeline or edit information in there :thinking:

Right, that part I didn’t answer as I wasn’t sure about it. The projects folder does contain a lot of detail, but it may not be everything. Is it all just in files or isn’t there also a database? Others may know more about where all the parts of a project are stored and how to back it up (other than making an archive).

It seems the safer route may be to make a second archive w/o media caches which is saved to another drive. That would leave it up to Flame to make sure everything is included and restorable.

That’s what I do at the end of a day in Flame. Update an archive w/o media caches/renders and save it on the NAS, which is then mirrored onto a LucidLink cloud file space. Anything happens, I should be able to pull that down reload the archive, find the rushes, and continue on. If I’m not mistaken. Because it doesn’t include media, those archives are usually < 2 GB.

Thanks guys. Yeah I guess I’m just trying to find a set and forget/procedural solution, that doesn’t risk human error

I’ve set up a weekly rsync of /opt/Autodesk/project to our NAS, which should stay pretty small and we can keep forever. Again this is just for the very unlikely situation that an archive is requested but the LTO tape breaks or the archive corrupts

btw, looks like Workspaces are saved here

3 Likes

Updating this thread in case anyone visits in the future - sooooooooo backing up the /opt/Autodesk folder while Flame was open kinda broke my Flame install and Autodesk support wasn’t able to recover it without wiping data. I had to roll back my machine to a snapshot from the day before it corrupted

Moral of the story - don’t mess around with Flame install files unless you know what you’re doing I guess

Shame, it’d be nice to have a way of backing up Flame without manually archiving

Can you expand on what broke and how?

I’m struggling to imagine a scenario in which rsync’ing /opt/Autodesk/ would end up breaking anything.

I used cron to automate an rsync -a copy and left it overnight, with Flame open. When I came in the next day, heaps of files were missing from the opt/autodesk folder. Not sure how/why, I also find it weird. Maybe I did something wrong. I contacted Autodesk but because the uninstaller was broken, they weren’t able to uninstall without wiping the whole folder. There are also a bunch of symlinks in /opt/Autodesk which didn’t get carried across in the copy.

According to Autodesk, archiving is the only officially supported backup workflow and they can’t guarantee data recovery if you back up using other methods.

Maybe there’s a way of getting it working, but I’ll leave it to others to experiment

Hmm. Weird @PatrickC . Every Flame Sysadmin I know backs up /opt/Autodesk.

Interesting. Thanks for the color.

For what it’s worth, I rsync files from /opt/Autodesk/project/{project}/ pretty much every night without any issues. That saves what to me is the only truly important part of the project which is the setups. Everything else can be rebuilt(however painfully).

It won’t let you rebuild the entire project the same way you might be able to if you had /opt/Autodesk/clip/, but I’m honestly not sure it would even be possible to rebuild a project from there anyway.

Pretty much everything else in /opt/Autodesk/ besides those two folders is irrelevant to the project data.

What’s the difference between backing up /opt/autodesk and an archive (without renders and media cache)?

I assume there would be a way via python script to automate running the archive process and copy it offsite? That way you would stay within the official workflow.

Of course an extra filesystem backup for H-S moments never hurts.

Take this with a grain of salt because I haven’t messed around with this stuff in years, but the way I would think about it is that backing up /opt/Autodesk/clip/ is for more immediate issues where the database may have become corrupted but the actual frames still reside on the framestore. Archives are for when the project has been removed from the Flame and it needs to be restored.

Archives can be done via the command line so it should be relatively straightforward to automate via python.

1 Like

What was your exact rsync command? There’s way to keep sym links but also it should never delete or touch anything on the source directory so it’s hard to see how it could botch your install.

I would say though that backing up something that could be updating whilst said backup was going on isn’t the best idea.

FWIW, I use Carbon Copy Cloner to backup my system disk to a diskimage on my NAS. I think all CCC does is access rsync ???

Hey Patrick,

And what about archiving every day your timeline work without including media, rendering and Hard commit in another disk dedicate to Light Archive ?

I’ve been using rsync to backup /opt/Autodesk (what used to be /usr/discreet) since starting with Smoke way back in 2008. Somewhere in the documentation, it was suggested to stop stone+wire before backing up so that the DBs get a clean backup. Then re-enable stone+wire and get on with things.

Here’s my short and simple script for Linux:

#!/bin/sh

#stop stone+wire to prevent project database problems
/etc/init.d/stonewire stop

#backup Autodesk folder to internal backup drive
#/usr/bin/rsync -avt --delete --progress --stats --human-readable --log-file=/root/rsync_log.txt /opt/Autodesk /mnt/backup_drive

#backup root system to internal backup drive
rsync -aAXvlH / --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/lost+found","/Volumes/*","/hosts/*"} /mnt/250 --delete --progress --stats --human-readable --log-file=/root/rsync_log_system.txt

#backup SSD framestore to internal drives
rsync -aAXvlH /mnt/SSD /mnt/stone_backup/backup/ --delete --progress --stats --human-readable --log-file=/root/rsync_log_ssd.txt

#start stone+wire so flame is ready to go again
/etc/init.d/stonewire start

#end

I used to only backup /opt/Autodesk before hard disks were cheap enough to not care as much. I left that line in there but commented out. The next two lines are the backup I use now. The first one backs up the root filesystem but excludes several folders that would be rebuilt with a new system install, etc. The second line backs up my frame store as a separate step - I have that going to a different backup drive and keep a separate log for it.

So, since around 2008, I’ve had some version of this script scheduled in root’s crontab so that it runs daily at 5:15 a.m.

crontab -e
15 5 * * * /root/rsync_backup.sh

You can keep track of what rsync does by reviewing the log files in the script. If you have a lot of churn, the log files can grow to be several GBs over time. I don’t have any log rotation or trimming built into the script, so from time to time I just manually delete or reset the log files. Easy enough for my needs.

Hope this helps.

1 Like

Central S+W server for the win here again boys. Built in transparent BG backups.
Local frame store workflow is utterly archaic.

1 Like