3.3 - backups
Working with computers there is always a lot of talk about the importance of saving your
work often, and to back it up. In the workplace, and as a student we're often told to keep
this in mind at all time, but rarely educated specifically on good methods for achieving this.
Described below are the backup methods I've settled on.
3.3.1 incremental filenames
Working with incremental file names is a must. I've found that each file class require a
slightly different backup procedure:
For short documents I usually I keep but a single file. On a document where keeping previous
iterations intact is important, generally with long documents and particularly with co-
authored documents, I start on a new editing session by renaming the document to the
current date. E.g. "project report - 2011-01-25".
184.108.40.206 two-dimensional files
Large 2D files such as textures and drawings can easily take long enough to save that it may
interrupt the creative flow of the work done. I therefore don't backup 2D files as often as 3D
files, and keep a less strict, less scientific incremental process. Roughly speaking, I tend to do
a temporary cyclical iteration of files from about 00 through to 05 and back, that are deleted
once I've arrived on a permanent new version number.
220.127.116.11 three dimensional files
Most 3D programs have some way that you can crash them or make the data in them
become unstable. In order to avoid losing valuable time, this calls for the most stringent of
the filename incrementing methods.
18.104.22.168.1 the save shortcut
The "save" shortcut. I make it a semi-conscious habit to press the program's shortcut
key for saving. An exception to this rule is if I'm attempting something I suspect or know
might make the program unstable. In these cases hit the shortcut to save first, then don't
save again until I've completed the risky procedure. This to protect the last assumedly safe
file. Once the unstable procedure is complete, I increment the save numerically.
22.214.171.124.2 when to save
Just about any changes followed by a break in muscular activity warrants a quick visit
to the save shortcut. Particularly so if working on an unstable process, or when many
changes are being made in a short space of time. If a row of changes are being made without
a natural break, stopping to save midstream is a good idea. Always save and then
immediately iterate whenever you felt like a part of your creation came out well, an obstacle
was overcome or it seems a great space of time has passed since the previous iteration.
126.96.36.199.3 numerical extensions
Depending on the number of files expected, I choose the size of the numeric file
name extension. I usually start with a "_00" extension and count upwards. If the numbers go
into three digits, renaming the original double-digit files to triple digits is a very good idea, to
(c) sverre andré kvernmo - www.sverror.com
keep file groups structured well within their folder. If you change the root name (e.g. from
creature_ to monster_) of the workfile during the project, making the name change to all
previous iterations also helps keep the file system accessible and clean. Avoid single digit
extension like monstermodel3, monstermodel7, etc. as these aren't as easy to read and pick
out in a folder as properly identified incremental files. Adding an "_" (or underscore) then
double digits, makes the file group easy to separate from other folder files, or file groups.
188.8.131.52.4 catching yourself
It is possible to get immersed in your work and forget to save for a while. Whenever
you catch yourself doing this, the recovery steps are threefold. First of all, fight the reflex to
simply save onto the current (and now relevantly old) file (e.g creature_151). Instead, save
the mid-process-I-just-caught-myself file to the next increment (e.g. creature _152) and then
continue working at the next increment (e.g. creature _153). This way you have:
a) kept the most likely safe file 151 and avoided applying any potentially unsafe data added
in the relative long space of time that has passed before you caught yourself.
b) saved a "stepping-stone-increment" in file 152 which represents a relative large amount
of work when compared to the average increment.
c) started on an all new adventure in increment 153, in which you are, within reason, free to
forget yourself in the creative process once again.
It might seem odd to iterate the file numeric twice once you catch yourself forgetting
to iterate, but it is the safest way to keep all your work. Omitting the second iteration when
you catch yourself (file 153), runs the risk of creating a collision between the many changes
from 151 to 152 and the many changes that might arise from forgetting yourself
consecutively, or twice in a row. Thus creating a large gap in the iteration of work saved.
This meticulous iteration method is most useful while working with unstable
software, or when in a creative fork-in-the-road where experimenting with the differing
possible paths might eventually necessitate stepping back an iteration or two. Worst case
scenario is that you at one stage were happy with where your creation was going, then
overworked away from it and thus lost the opportunity to revert to where it was good.
Valuable time and momentum may be saved using this method.
184.108.40.206.5 naming milestone and experiment extensions
Since file iterations can reach into the 100s, it is helpful to make special names for
milestone or experimental files. I then add a second extension behind the numerical one,
signifying what the significance is. E.g. "creature_090_sculpting-complete".
This makes it easier to review the file group in retrospect and helps in selecting what
numbers to keep once the file's current version is finished. My preference is to keep every
tenth file, and/or any such named files. Keeping entire sets of file iterations that reach three
digits is not recommended, as they are unwieldy in the file browser (e.g. window explorer)
and are likely to cause the size of your backup library to swell.
3.3.2 the double reverse backup
I regularly backed up my project using a "double reverse backup". This means taking the
workspace on the PC's internal hard disk, backing it up once onto an external hard disk, and
then copying the backed up data back to the internal hard disk, into an incrementally dated
folder system. The folders in this system are created to be listed chronologically if listed by
name, and so dates are typed in the order which the computer lists numbers (0 first, then 1,
(c) sverre andré kvernmo - www.sverror.com
then 2, etc.). E.g. the folder containing the data for the-day-before-christmas-of-last-year
would read "backup 2010-12-23", rather than "backup, 23/12-2010" as might be the proper
hand-written form for such a date. This is to make the backup folder more easily accessible
and avoid illegal computer file name characters, such as "/" (and, notably, "?").
Advantages to having an external hard disk holding the most current backup:
- Double hardware failsafe. Some times hard disks cease to function, and the data on them
might at worst be unrecoverable, or expensive to extract at best. With two hardware-
separate copies of your recent data, both internal and external hard disks would have to
break at the same time for data loss to be complete.
- Mobility. An external hard disk allows the backed up data to be transported without the
necessity of bringing the entire computer rig along. Bringing the external disk along while
travelling, can for instance safeguard data from rig theft.
- Fastest external backup method. Two separate hard disks means easy disk-to-disk file
transfer, and large storage capacity, eliminating cumbersome CD/DVD backups, limited sized
stick-disk backups or other cumbersome methods.
- trickling data. At certain times, data that has been moved out of the current workspace (for
size, age or tidiness) and into the backup library might need editing. You could have folders
full of holiday pictures, long music playlists or, as is the case for this project, large texture
libraries, that you'd rather have backed up than sitting in the current workspace. Once this
data require editing, the modifications should be done on the primary backup platform,
namely the external hard disk. This way you don't have to make an entire workspace backup
for the sake of making minor adjustments to large sets of data. On the next backup iteration,
the changes made are catalogued. This also solidifies the internal backup library as a non-
write zone, meaning you don't have to worry yourself about improving any of the data there
(bar the deletion of eventually redundant data or swelling data sizes). Data improvements to
backups are done only on the primary backup platform - the external hard disk. This means
you should have a structured folder system that doesn't exist in the workspace, but is unique
to the backup space. These folders is where the large data set changes are trickled into.
- Personally I try to backup using this system about once a month, depending on the amount
of data activity. For highly important files that might need day-to-day backup, I currently use
(c) sverre andré kvernmo - www.sverror.com